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OBJECT-ORIENTED  APPROACH  TO  THE  SOFTWARE  DESIGN 
FOR  AUTONOMOUS  DECENTRALIZED  SYSTEMS 


We  aJso  develop  & trenaformatioo  melbod,  by  wbicb  the  module  interfeces  ere 
systemeticelly  eiteblisbed  from  the  decompoied  dete  How  diagrams  in  the  software 
design  phase.  In  our  transformation  method,  the  activation  relationship  between  the 
components  of  the  data  flow  diagram  are  used  to  decide  the  direction  of  each  remote 
object  method  invocation.  Finally,  the  effective  utilizatioo  of  ADS  environments  is 


CHAPTER  1 
INTRODUCTION 

Du«  to  the  repid  developmeot  of  computer  end  communJcation  technolopee,  dis* 
tributed  computing  eysteniB  ate  used  in  various  application  areas.  Moat  of  those 
applications  are  directly  related  to  our  human  society  enviromneot  that  is  dynatn* 
ically  chan^og  and  frequently  growing.  The  requirement  of  a new  concept  of  a 
computing  system  based  on  newly  developing  teehnolopes  is  strongly  emerging.  In 
some  applications  of  distKbuted  computing  systems,  we  cannot  stop  the  system's 
operation  during  the  life  cycles  of  the  system.  Tb  satisfy  the  requirements  of  those 
application  areas,  the  computing  systems  should  be  reliable,  adaptable  and  expand* 
nble.  Fbr  example,  a process  cootrol  system  in  a steel  industry  can  never  be  stopped 
in  its  operation  at  any  time,  including  partial  system  faulty  time,  system  expansion 

only  n fault  tolerance  capability  but  also  on.line  expansion  and  on*line  maintenance 
properties.  However  it  Is  dilScull  to  attain  these  software  on*line  properties  by  the 
distributed  computing  system  based  on  conventional  techniques  [38].  In  conventional 
operating  systems  and  languages,  every  software  subsystem  or  specific  mansger  needs 
to  know  the  partial  and/or  total  system  structure  represented  by  the  communication 
relation  between  software  subsystems.  However,  Id  s large  and  complex  system  that 
is  partially  damaged  and  and/or  recovers,  it  becomes  difficult  to  mooage  the  whole 
system  with  such  approaches. 

A new  system  technology,  the  Autonomous  Decestralised  System  (ADS)  was  de- 
veloped [29,  30,  38|.  An  ADS  Is  a kind  of  a dislribuled  computing  system  to  attain 


on-Uae  expudabllily,  cmOiae  maiptunability  and  fault  tolerance  of  a software  sys- 
tem as  well  as  a hardware  system.  The  environmeola,  such  as  the  system  software 
itruetures,  of  these  systems  are  differenl  from  those  of  general  distributed  comput- 
ing systems.  By  these  system  software  structures,  the  autonomy  properties  of  each 
distributed  processor  is  satisiied,  and  on-line  testing,  on-line  expansion,  data  consis- 
tency and  fault  tolerance  of  application  software  are  effectively  supported  |38|.  On 
the  other  hand  the  application  software  development  technology  for  these  ADSs  have 
not  yet  been  studied  adequately,  although  the  need  for  that  technology  is  very  high. 

There  are  three  approaches  to  the  software  design  for  distributed  computing  sys- 

oriented  approaches  are  considered  to  he  the  most  promising  ways  to  develop  dis- 
tributed computing  software  and  parallel  computing  software  [59,  60,  61).  However, 
currently  koown  object-oriented  approaches  sre  too  general  to  apply  in  the  ADS 
application  software  development.  In  those  approaches,  the  specific  requirements  of 
the  ADS  application  software,  such  as  on-line  expansion,  are  not  considered.  Fu^ 
thermore,  conventional  object-oriented  computation  models  do  not  fully  address  the 
features  of  the  ADS  environment,  for  example,  locationaJly  transparent  inter-module 
access  based  on  broadcasting  mechanism.  In  the  conventional  object-oriented  con- 
cept, the  relationship  between  interacting  objecta  la  a client/server  relation.  The 
software  systems  ba-sed  on  the  client/server  relation  are  difficult  to  achieve  on-line 
properties  (36).  Therefore,  there  are  some  limitations  in  the  development  of  ADS 
application  software  using  the  object-oriented  approach  baaed  on  the  conventional 
object-oriented  computation  model.  So,  a new  computation  model  for  the  develop- 
ment of  application  software  of  ADSs  is  required. 


Among  applicotioD  areas  of  distributed  computing  systems,  data  flow  type  of 
applications,  such  as  process  control  system,  are  much  more  suitable  for  the  appli- 
cation of  the  ADS  than  client/server  type  of  appticatioDS,  because  the  interactions 
among  the  software  modules  in  the  former  type  of  applications  are  primarily  based 
on  the  data  flow  concept.  In  the  data  flow  type  of  applications,  there  are  several 
asynchronously  generated  input  data  or  external  signals,  and  the  software  system 
proceasea  ita  task  after  reemving  these  data  or  signals  and  generates  some  output 
data  or  signals,  foe  the  reaction  to  the  external  environment,  or  for  the  input  data 
or  activation  of  subsequently  proceased  tasks.  Data  flow  diagrams  are  very  suitable 
models  to  represent  the  characteristics  of  these  applications.  So,  in  the  requirement 
analysis  phase  of  the  software  development  approach  for  ADSa,  the  data  flow  dia- 
gram is  a primary  model  to  describe  the  system  characteristics.  On  the  other  hand, 
conventional  object-oriented  models  used  in  Ibe  design  phase  of  tbe  object-oriented 
software  development  approach  are  based  on  the  client/server  type  of  interaction. 
So,  there  should  be  some  methods  or  techniques  which  smoothly  link  two  successive 

One  way  to  solve  this  problem  is  by  incorporating  the  data  flow  concept  into 
the  object-oriented  concept  and  using  a transformation  method  to  transform  a data 
flow  diagram  into  a module  diagram  based  on  tbe  incorporated  concept.  In  this 
approach,  we  do  not  need  to  develop  a requirement  analysis  method  and  its  related 
models,  i.e.,  we  can  use  the  data  flow  diagram-based  requirement  analysis  approaches 
like  the  structured  analysis  method.  Abundant  well  developed  software  tools  are 
available  for  the  data  flow  diagram  based  requirement  analysis.  Tbe  customer  and 
software  requirement  analyser  need  not  learn  the  new  method  to  meet  the  agreement 
of  the  system  requirement-  Still,  conventional  analysis  methods  can  be  used  in  the 
requirement  analysis  phase. 


Another  approach  to  overcoiriing  this  problem  it  ueing  an  object-oriented  model 
in  the  requirement  analyeis  phase.  This  approach  ia  much  more  consistent  because  it 
uses  almost  the  same  models  in  both  phases.  However,  this  approach  may  not  fully 
aopport  the  requicemcnt  analysis  of  the  data  Sow  type  of  application  software.  It 
also  lacks  supporting  software  tools.  The  customer  needs  to  learn  the  new  method, 
even  though  he  or  she  may  already  know  about  the  data  Sow  diagram  based  method. 

In  this  dissertation,  an  object-orieuted  design  approach  is  presented.  We  primarily 
invstigate  an  object-oriented  computation  model  for  the  basis  of  the  develrspment 
of  the  ADS  application  software  and  a transformation  method  for  the  early  design 
phase  of  the  ADS  application  software  development.  Among  the  design  issues  of  ADS 
application  software,  we  focus  on  the  on-line  expandable  ADS  application  software. 

This  dissertation  ia  organised  as  follows.  In  Chapter  2,  background  informatiou 
is  presented.  This  chapter  ahows  the  overview  of  the  ADS  including  the  concept  and 
system  software  structure  of  the  ADS.  Properties  of  distributed  compulation  models 
are  described.  Each  property,  especially  object-oriented  compulation  models,  is  dis- 
cussed from  the  viewpoint  of  the  ADS.  The  major  issues  on  ADS  application  software 
and  comparison  of  the  software  design  methods  for  distributed  computing  systems 
are  also  summarized  in  this  chapter.  In  the  laat  part  of  this  chapter,  the  assumptions 
and  scope  of  this  dissertation  arc  summarized.  In  Chapter  3,  the  overall  picture  of 
our  software  development  approach  for  ADSs  is  presented.  Required  tasks  and  input 

In  Chapter  4,  the  features  of  our  computation  model  are  presented  with  emphasis 
on  encapsulation,  synchronization,  method  invocation,  exception  handling,  logically 
locational  transparency,  and  the  data  flow  concept.  In  Chapter  fl,  the  operationaJ  se- 
mantia  of  object  method  invocations  in  our  computation  model  is  formally  defined 
by  usiog  the  transition  system.  In  Chapter  6,  input  and  output  models  for  ADS 


software  desige  phase  and  the  design  description  language  are  presented.  In  Chap- 
ter 7,  the  transformation  rules  for  the  establishment  of  module  interfates  from  the 
decomposed  daU  flow  diagram  are  shown.  The  activation  relationship  between  the 
components  of  the  data  flow  diagram  is  discussed  in  this  chapter.  Chapter  8 shows 
our  design  steps  and  an  example  of  our  ADS  application  software  design  approach. 
Finally,  in  Chapter  9,  a snmmary  of  the  results  and  some  remarks  are  pven  and  also 
direction  for  future  work  Is  discussed. 


CHAPTER  2 
BACKGROUND 


Id  this  cIiDpter,  we  present  on  overview  of  the  ADS  Dad  survey  existing  compu* 
tetioD  roodeli  kr  distributed  computing  systems  end  software  design  methods  for 
distributed  systems. 

2.1  Overview  of  ADS 

?.1.1  ADS  Concent 

The  ADS  concept  is  based  on  a biolo^cal  analogy  and  has  the  perspective  that 
a system  almost  always  has  faulty  parts  and  undergoes  modidcations  [3B,  31, 41].  It 

defined  it  mathematically  with  combining  the  control  theory. 

DeRnituin  S.7.1  5u&jyjtem 

A subsystem  Ss  is  a distributed  computing  system  unit  wbieb  includes  o separate 
Aerdvare  processor  wilb  its  oom  system  soflwart  and  appliealion  sofivare  in  that 

The  ADS  5«ai  consists  of  a set  of  subsystems,  i.e.,  St  E StSM>  Each  subsystem 
serves  to  control  some  part  of  the  whole  system’s  functions.  That  means  the  whole 
system's  functions  are  performed  by  the  integration  of  each  distributed  subsystem's 
operation.  Each  subsystem  has  responsibility  for  controiling  its  related  computing 

gefailion  S.I.S  Aulanamaus  eontnllabilily 

The  system  has  autonomous  eontrollability  if  the  foUouring  condition  is  satisfied: 

If  any  subsystem  fails,  the  other  subsystems  ran  continue  to  manage  Ihemseloes. 


The  eutoDomoiis  ccntrollabiUty  meaju  thet  e&ch  subsystem  is  self-coDtrollable 
and  can  centrol  its  own  area  without  regard  to  other  subsystems'  conditions. 
nfgniriea  t.I.S  Xutonomous  coordinaWily 

Tht  system  has  autonomous  coordinability  if  the  fotlouhny  eondilion  is  satisfied: 

If  any  subsystem  foils,  the  other  subsystems  can  coordinate  their  indimduat  ohjectives 
omony  themseloes. 

The  autoaomous  coordinability  means  that  a system’s  reliability  is  kept  by  process 
continuity  when  any  subsystem  fails,  i.e.,  the  other  subsystem  can  coordinate  their 
individual  objectives  among  themselves. 
neffnition  SJ.d  Autonomous  tHecentrotired  System 

A system  is  catted  an  autonomous  decentralised  system  if  it  has  ftoo  autonomous 
properties — autonomous  controllabitity  and  autonomous  coordinability. 

An  ADS  system  consists  of  a setof  distributed  software  subsystems.  Thesoftware 
subsystem  includes  system  software  modules  (subsystem  software)  and  application 
software  modules. 

To  realise  an  autonomous  decentralized  software  system  with  autonomous  proper, 
tics,  each  subsystem  software  residiog  in  a distributed  processor  is  required  to  satisfy 
the  following  conditions  |38j: 
aj  uniformity; 
bj  equality; 

C.1  locality. 

In  the  ADS.  each  subsystem  software  must  be  uniform.  Every  subsystem  soft- 
ware's  function  is  self-cootaioed.  The  subsystem  software  can  manage  its  own  appli- 
cation software  modules  without  being  dependent  on  the  other  subsystem  software 


fuuctioDB.  Even  if  the  aubaystem  aoflwere  in  some  processors  stop  oper&tion,  the 
other  subsystems'  software  cao  continue  opemtiem. 

There  is  no  mnster'siave  relation  among  the  software  of  the  subsystems.  Every 
subsystem  software  can  manage  its  own  applicatioo  software  moduJea  without  being 
directed  by  or  giving  directions  to  the  other  subsystem  software.  This  condition 
assures  that  each  subsystem  software  can  continue  its  operation  even  if  the  other 
subsystem  software  functions  fail.  Each  subsystem  software  must  be  able  to  manage 
its  own  application  software  and  itself,  as  well  as  coordinate  sdlb  other  subsystems' 
software  based  only  on  local  information. 

9.12  ADS  Software  Structure 

It  is  dil^cult  to  satisfy  the  above  three  conditions  based  cm  the  conventional 
software  structure  aod  its  managemeot  technique.  On  the  other  band,  with  the  au- 
tonomous decentralized  software  structure  [36],  these  three  conditions  are  successfully 
satisfied. 

Tbe  bauc  feature  introduced  in  the  Autonomous  Deceutralized  Software  Struc- 
ture is  the  Data  Field  (DP)  where  the  data  circulate  among  the  modules  in  tbe 
software  subsystem  129).  In  the  DF,  each  message  has  a content  code  that  indicates 
its  meaning.  Tbe  software  module  broadcasts  a message  with  the  content  code  into 
tbe  DF,  and  it  judges  whether  or  not  to  receive  the  message  from  the  DF  on  the  basis 

transparent  and  one-way  directional.  Any  module  can  communicate  with  any  other 
module  connected  to  the  DF.  Every  software  module  in  the  subsystem  software  and 
the  applicatioo  software  Is  a functional  unit  that  receives  data  from  the  DF  and  sends 


out  data  into  the  DF. 


The  subsystem  softwaxe  coiuists  of  a DF  managemeiit  module,  j 


Bgemect  module,  4 bui]t*in  tester  module,  a coostruclion  managemeDt  module  and 
a data  consistency  management  module.  The  DF  management  module  receives  mes* 
sages  from  the  DF  or  sends  (broadcasts)  messages  to  the  DF.  It  updates  a table 
that  includes  the  relationship  between  the  application  software  module  is  the  soft- 
ware subsystem  and  the  content  codes  necessary  to  execute  this  application  software 
module.  The  execution  management  module  monitors  the  table.  This  table  is  called 

application  software  modules  in  each  processor.  As  soon  as  all  the  necessary  data 
for  the  application  software  module  are  received  in  the  table  by  the  DF  management 
module,  the  execution  management  module  drives  the  application  software  module. 
The  built-lo  tester  module  tests  application  software.  The  construction  management 
module  supports  application  software  loading  and  expansion.  The  data  consistency 
management  module  checks  the  replicated  data  received  from  duplicated  modules 

fault-toleranee  of  the  ADS.  The  application  software  of  ADS  consists  nf  modules 
that  execute  their  tasks  independently,  Each  application  module  is  controlled  by  the 
system  software  modules  that  reside  in  the  same  proceasor.  In  figure  2.1,  an  example 
of  the  modular  structure  of  each  software  aubsystem  for  AOS  is  shown.  Originally, 
the  figure  was  presented  in  Mori  et  al.  [38). 


In  principle,  any  language  can  be  used  to  program  a distributed  application. 
However,  a pre^rammer's  work  is  greatly  complicated  if  the  source  language  does  not 
contain  constructs  or  high  level  ahstraclion  meehaniemi  oriented  to  the  needs  of  dis- 
tributed programs  (48).  As  distributed  applications  become  more  commonplace  and 


' 9opbislic«ted.  the  nood  for  « distributed  computation  model  and  its  language 


become  greater.  Many  distributed  computation  models  and  languages  have  been  in* 

of  this  section,  because  it  naturally  supports  the  object-oriented  design  methodology 

2.2.1  Prooerlies  of  Distributed  CompuUlion  Models 

There  ace  several  diflerent  types  of  distributed  computing  systems.  Each  type  ha.s 
its  own  advantages  and  some  limitations.  Even  though  the  types  are  different,  there 
are  common  issues  to  be  addressed,  including  the  following  major  ones  |7j: 

• granularity  of  parallelism; 

s fault  tolerance. 

Because  a distributed  system  has  more  than  one  processor,  it  is  naturally  required 
to  have  mote  tbao  one  pact  of  a program  running  at  the  same  time.  The  granularity 
of  parallelism  in  a computation  model  ranges  from  the  process  (e.g.,  in  Concurrent 
C (52))  to  the  expression  in  functional  computation  model  (e.g.,  ParAll  |28)  and 
PROOF  (60|).  The  granularity  of  parallelism  is  dependeol  on  the  coal  of  communi- 
cation io  the  distributed  system.  In  a system  with  high  communication  cost,  such 
as  a WAN,  or  a system  with  relatively  high  commuoication  ccsl,  such  as  a LAN, 
the  communication  cost  of  ffne-graioed  parallelism  may  not  outweigh  the  advantage 
gained  by  parallel  computation.  In  an  ADS,  the  inter-subsystem  communication  cost 
is  relatively  high  because  the  communication  among  subsystems  in  the  ADS  is  based 


I broadcAflt  mecbanjsm  within  a LAN  environment.  So, « 


is  more  suitable  at  the  inter'subsystem  level.  In  case  that  parallel  machines  are  In- 
cluded in  the  ADS  conliguration.  a hnc  grained  or  medium  grained  parallelism  also 
needs  to  be  coosidered  at  the  intra-subeystezn  level. 

Parallel  processes  in  a distributed  computing  system  cooperate  with  each  other. 
This  cooperation  requires  two  types  of  interaction:  communication  and  synchro- 
nisation. interprocess  communication  is  done  by  message  passing  or  shared  memory. 
Usually,  processors  ioteracting  through  a shared  memory  system  are  strongly  coupled 
and  processors  ioteractiog  with  a message  passing  mechanisms  are  loosely  coupled. 
From  the  ADS  viewpoint,  a loosely  coupled  processor  has  a higher  degree  of  auton- 
omy than  a strongly  coopled  processor.  On  the  other  band,  a shared  memory  system 
can  easily  support  the  locational  transparency  in  the  processor  interactioo.  A pro* 
cess  sending  data  need  not  know  the  location  information  of  the  destination  process 


.ta  from  that  area.  Linda 
[21,  13,  34]  is  a computation  model  based  oo  the  shared  memory  concept  called  a 
tuple  space,  in  the  case  of  one-to-one  communication,  the  tuple  space  is  a very  sim- 
ple way  to  achieve  interprocess  communication.  However,  K periodic  data  or  control 
signals  are  sent  to  more  than  two  destinations  (ooe-to-many)  at  the  same  time,  it  is 


not  simple  to  describe  the  interprocess  communication  with  the  tuple  space. 

The  major  design  issue  for  a message  passing  system  is  the  choice  between  syn- 
chronous and  dsyncAronous  message  passing.  In  a distributed  system  with  syn- 
chronous message  passing,  the  sender  is  blocked  until  the  recover  has  accepted  the 
message.  In  this  case,  the  sender  and  the  receiver  are  synchronized  by  exebaoging 
tbe  data.  In  a system  with  asyoebronous  message  passing,  the  sender  doa  not  need 


each  other  by  ooe-way  eommunicatioo.  Even  though  the  two-way  cormnuoication 
increaaee  the  degree  of  depeodeocy  and  reduces  the  autODomy  of  each  distributed 
software  module,  the  ahstractioo  of  the  two-way  communication  cao  raahe  it  much 
easier  than  the  ooe-way  commuoicalioo  to  desigo  software  modules  among  which 
client/server  type  ioteractioos  are  inherently  required.  Using  the  higher  level  con- 
struct for  the  two-way  communication,  the  software  designer  need  not  worry  about 
the  low  level  detsuls  of  communication  protocol  and  their  correctness. 

Rendexvonj  sod  remote  procedure  call  are  well  known  as  single  higher  level  con- 


tbe  rendesvous  model.  The  rendezvous  model  consists  of  three  parts:  the  entry  dec- 
laration, the  entry  call  and  the  accept  statement.  The  entry  declaration  and  accept 
statement  are  dchned  in  the  server  code,  and  the  accept  statement  is  defined  in  the 
cHeot  code.  The  sender  and  the  receiver  are  fully  synchronised.  When  the  sender 
and  the  receiver  are  syncbronized  they  continue  their  execution  concurrently,  The 
receiverexecutes  the  sender's  requesting  work.  Distributed  Processes  [11|  and  LYNX 
[46]  are  based  on  the  remote  procedure  call.  A remote  procedure  call  is  similar  to  a 
normal  procedure  call  in  a sequential  program,  except  that  the  caller  and  the  receiver 
are  different  processes.  After  the  sender  calls  s remote  procedure  in  the  receiver,  the 
sender  is  blacked  until  the  receiver  finishes  executing  its  i:alled  procedure  and  sends 
back  the  result  of  processing  to  the  sender. 

The  choice  between  one-to-one  and  one-to-many  is  another  design  issue  for  a mes- 
sage passing  system.  Most  computer  networks  used  for  distributed  computing  sys- 
tems support  s fast  broadcast  or  multicast  facility.  One-to-many  communication  baa 
several  advantages  over  one-to-one  communication.  If  a process  needs  to  send  data 
to  many  other  processes,  a broadcast  or  s multicast  is  an  effective  way,  A broadcast 
primitive  preserves  the  order  in  which  messages  are  sent  [19).  This  order  preservation 


].  Ada  and  Concurrent  C [20]  are  based  on 
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cbar»clerutic  is  very  useful  for  oxislstent  updating  of  replicated  data  The  broad- 
cast primitive  supports  locational  transparency  for  accessing  resources.  Locational 
transparency  is  a very  desirable  trait  for  distributed  computing  systems  [45|.  The 
location  of  each  software  module  in  the  ADS  needs  to  be  logically  as  well  as  physically 
transparent.  That  means  each  software  module  sends  data  to  other  modules  without 
information  about  the  destination  module's  physical  address  and  identification.  The 
locational  transparency  increases  the  autonomy  of  each  distributed  software  module. 

lies  of  the  AOS.  Fbr  these  reasons,  locational  transparency  at  the  application  software 
level  and  broadcast  programming,  by  which  a software  designer  can  utilise  the  ADS 
environmeot  elFectively,  should  be  supported  in  the  design  of  ADS  software.  Gebaui 
(19|  proposed  Broadcasting  Sequential  Processes  (BSP)  bssed  on  CSP  (27|  and  the 
concept  of  broadcast  programming.  However,  BSP  does  not  have  an  object-oriented 
concept.  FLAME  (42),  which  is  an  experimental  language  for  distributed  program- 
ming, is  based  on  object-oriented  and  process  group  concepts.  Tbe  process  group 
feature  is  the  ability  to  aend  broadcast  messages  to  group  members.  In  order  to  send 


a message  to  each  member  of  group,  a client  sends  a single  message  to  the  group.  So, 
FLAME  supports  logical  locational  transparency  partially  but  not  completely. 

One  of  the  major  goals  of  distributed  computing  systems  is  fault  tolerance.  Dis- 
tributed computing  systems  are  potentially  more  reliable  because  of  their  partial 
failure  properly.  Distributed  processors  have  their  own  system  software  and  they 
are  loosely  coupled  via  communication  network  environments.  So.  a failure  in  one 
processor  docs  not  directly  affect  the  correct  functioning  of  other  processors  except 
when  they  communicate  with  each  olher.  The  system  software  and  network  protocol 
support  reliable  data  communication  among  distributed  pcocMses.  Reliability  can 
be  increased  by  replicating  tbe  functions  and  data.  In  the  ADS,  fault  tolerance  is 
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jupport«<i  by  the  system  software  by  the  data  and  process  replication  method.  Even 
though  the  system  software  supports  fault  tolerance,  it  still  does  not  guaraolee  com- 
pletely reliable  operation  for  the  application  software.  Therefore,  some  mechanism 
for  fault  tolerance  at  the  application  software  level  is  required. 

Ad  object-oriented  computation  model  Is  based  on  object  and  class  coocepts.  A 
class  is  the  extension  of  the  notion  of  an  abstract  data  type.  The  class  in  so  object- 
oriented  paradigm  has  an  inheritance  concept.  A class  may  Inherit  the  operation  and 
the  behavior  of  a superclass.  This  inheritance  property  supports  the  reusabibty  of 
software.  Every  object  is  an  instance  of  some  class. 

An  object  is  an  entity  that  encapsulates  some  private  data  and  a set  of  associated 
operatioDB  that  manipulate  the  data.  The  private  data  are  protected  and  invisible 
from  tbe  outside  of  the  object.  The  only  way  they  can  be  examined  or  acrtywyl  is  by 
the  invcKatioD  of  one  of  the  object's  dehned  methods. 

Tbe  languages  C-l-4  [50]  and  Smalltalk  [23|  are  well-known  object-oriented  lan- 
guages. Those  languages  are  sequential  programming  languages.  They  are  based  on 
a model  of  possios  okjitU.  A passive  object  does  not  have  Us  own  cootrol  tbresd.  It 
is  just  invoked  and  one  of  its  methods  is  executed.  Fundamentally,  its  method  invo- 
cation is  similar  to  subroutine  calls  in  imperative  languages.  Conceptually,  an  object 
is  a parallel  unit  in  the  real  world.  Black  et.  al.  suggested  that  “an  object  model  is 
appropriate  fora  distributed  system  because  it  implicitly  deHnes  (1)  the  unit  of  distri- 
bution and  movement  and  (2)  tbe  entities  that  communicate"  [10|.  Each  object  may 
represent  a Mparate  thread  of  contrrd,  i.e.,  a process  abstraction.  Such  objects  are 
called  aefise  oijtttt.  In  a distributed  computing  system  based  on  an 


. object-oriented 


model,  we  can  conceptualize  the  world  as  consisting  of  a set  o(  cooperative  objects, 
some  of  wbicb  are  active  objects  as  centers  of  indepeodeot  activity. 

Basically,  tbe  properties  of  distributed  object-oriented  computation  models  are 
well  matcbed  to  the  requirements  of  ADS  software,  such  as  low  coupling  and  bigb 
cohesion,  expandability,  maiotainability,  etc.  ConcurrcotSmaJUalk  [62],  Emerald 
[6,32],  ABCL/1  (12, 63],  etc.  arc  examples  of  a distributed  computation  model  based 
on  tbe  object  concept.  ConcurreutSmalltalk  is  an  extended  version  of  Smalltalk,  ft 
has  a construct  for  asyocbronous  message  passing  to  iocrease  parallelism.  ABCL/1  is 
based  on  Actor  [1].  It  supports  asyocbrooous  message  passing  and  tbe  communica- 
tion is  baaed  ou  a client-server  model  using  Unix  sockets.  Emerald  is  an  object-based 
programmiog  language  for  the  implementation  of  distributed  applications.  Emerald 
provides  the  aame  semantics  for  local  and  remote  invocations  and  supports  locatioual 
transpareocy  for  object  invocalioo.  However,  it  does  not  have  classes  or  inheritance. 


ware  coostruction,  no  model  supports  one-way  communication-based  remote  object 
method  invocation  and  logical  locational  transparency. 


Even  though  tbe  system  software  supports  autonomy  of  each  subsystem  to  at- 
tain on-line  properties  aod  fault-tolerance,  the  application  software  of  ADS  also  has 
required  properties.  Most  issues  considered  in  the  software  development  for  general 
distributed  computing  systems  are  also  considered  inherenlly  in  the  development  of 
ADS  application  software.  Besides  tbe  general  issues,  addilional  specific  issues  such 
as  expandability  should  be  addressed  in  tbe  development  of  ADS  application  soft- 
ware. We  identify  the  following  issues  that  should  be  considered  ia  the  development 
of  application  software  underlying  ADS  environments; 


some  desirable  properties  for  ADS  soft- 


23  ADS  ApoUcatien  Software  [ssum 


• imjt  of  parallelism; 


• fault  tolerance; 


• eynchrODiaation  of  abared  resource  access; 

• expaodabUity; 

• modibabillty; 
s testability 

We  already  have  discussed  the  unit  of  paTallclIsm,  inter-process  cormnunicatloo 
and  fault  tolerance  as  primary  issues  of  general  distributed  computing  software  in 
Section  2.2.  Issues  particular  to  ADS  application  software  are  explained  in  tbia 


One  of  tbe  aims  of  the  distributed  computing  system  is  resource  sharing.  To  sup- 
port the  access  of  shared  resources  correctly  and  effectively,  synchronization  meeba- 
nisms  should  be  carefully  considered  in  the  development  of  ADS  software.  Synchro- 

communication  is  a much  more  suitable  mechanism  to  synchronize  shared  resource 


accesses  than  asynchronous  communication,  but  synchronous  cc 
reduce  tbe  autonomy  of  each  distributed  process.  Processes  which  cooperate  with 
each  other  by  the  synchronous  message  passing  mechanism  are  more  closely  coupled 
than  by  the  asynchronous  message  passing  mechanism.  One  process’s  interaction 
with  a synchronous  message  passing  mechanism  directly  affects  the  other  process’s 
control  flow  state.  So,  tbe  autonomy  properties  are  sacrificed  by  the  synchronous 
communication  mechanism. 
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Exp&odobility  is  stcoogly  required  not  only  in  the  berdware  but  also  in  the  soft- 
ware of  distributed  computiog  systems,  in  particular,  one  major  advantage  of  ADS 
is  on-lioe  expandability  of  hardware  and  software  systems.  Even  though  the  system 
software  in  an  ADS  environment  supports  the  on-lioe  expandability  of  application 

capability.  If  the  software  modules  are  more  autonomous  among  themselves,  the  ex- 
pandability of  such  systems  is  much  higher.  Software  structure  based  on  a data  Bow 
(data  driven)  concept  can  give  more  autonomy  to  each  distributed  software  com- 
pooent  than  that  based  on  a client/server  concept.  In  the  data  flow  concept,  the 
information  flow  is  one  way.  Bach  module  simply  accepts  data  from  other  modules 
and  then  sends  the  result  data  to  the  next  module.  A sender  module  is  not  affected 
by  the  internal  operation  of  the  receiver  module  except  when  the  data  flow  feeds  back 
to  the  sender  module.  On  the  other  hand,  software  modules  based  on  a client/server 
concept  are  more  closely  coupled  with  each  other.  In  the  clieot/server  concept,  the 
information  flow  is  based  oo  a two-way  commuoication.  The  server  module's  oper- 
ation affects  the  client  module’s  operation.  So,  two  modules  are  less  autonomous  in 
the  clienl/BCrver  model. 

Designiog  application  software  that  cao  be  modified  easily  is  also  important,  be- 
cause on-line  maiotenance  is  another  purpose  of  the  ADSs.  To  maximize  on-line 
rnaintaiuaUlity,distributedapplicalion  software  modules  loan  ADS  should  be  loosely 
coupled  and  they  should  have  a high  degree  of  autonomy. 

The  ADS  eovirooment  supports  oo-line  testing  of  each  distributed  application 
software  module.  To  utilize  this  on-line  testing  capability  effectively,  hierarchical 
unit  testing  is  required.  So  application  software  is  required  to  have  the  property  of 
nusdularity. 
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A distributed  softwsre  system  can  be  considered  a set  of  sequential  processes  with 

software  system  arc  asynchronously  executed  and  communicate  with  other  processes 
to  perform  a system*wide  task.  The  cbaracteristica  of  a distributed  software  devel- 

methodolo^.  Yau  [59]  defined  the  dilTerences  as  follows: 


The  processes  io  a distributed  software  system  can  be  executed  iu  parallel; 
The  processes  iu  a distributed  software  system  are  able  to  cooperate  with  one 
another  to  fulfill  a system-wide  task.  The  cooperation  involves  communication 
and  syuchronination  among  the  processes; 

Software  components  can  be  mapped  into  hardware  resources  by  partitioning 
and  allocating  software  components  baaed  on  the  structure  and  performance 
requirements  of  the  distributed  computing  system. 


Software  design  methods  for  distributed  software  systems  are  classified  as  data- 
flow-oriented,  communication-orieoted  and  objcct-oricuted(59j.  The  data-flow-oriented 
method  has  been  used  extensively  and  many  tools  for  supporting  this  method  are 
available.  Structured  Analysis(SA)/Structured  Design(SD)  [33,  65,  64]  is  a tradi- 
tional data-flow-oriented  software  design  method.  Because  communication  and  syn- 
chronization are  not  incorporated  in  the  design  phase  but  supported  by  concurrent 
programmiug  languages  in  tbe  implementation  phase  [49],  the  data-flow-oriented  ap- 
proach to  the  software  design  of  distributed  computing  systems  Is  the  same  as  that  of 
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fully  addren  tbe  coocurreocy  r«]ftt«d  i«mes  of  ADS  software.  It  hu  the  followlog 
drawbacks  wben  it  u applied  to  tbe  design  of  diatributed  software  ayslems[bkj. 


a inadequacy  for  applications  wilb  natural  concurrency; 

• inadequacy  for  supporting  communication  and  syncbrooiaation; 

• irresponsiveness  to  changes  in  tbe  problem  apace. 


On  the  other  hand,  the  data  Bow  diagram  is  good  for  the  representation  of  the 
requirement  analysis  for  the  data  Bow  type  of  application. 

Communicatioo'oriented  design  methods  deal  with  communication  aspects  erf  scdt' 

at  the  software  design  phase.  FVrnctional  aspects,  which  are  a primary  concern  in  tbe 
data-flow-oriented  methods,  are  considered  secondary  tasks  in  the  communication* 
oriented  design  methods.  However,  they  also  lack  a control  and  data  abstraction 
mechanism.  Varimis  Petri*net  methods  |43, 57, 5Sj  and  SREM  [4]  are  included  in  the 
class  of  communication-oriented  design  methods.  The  Petri-net  methods  have  ad- 
vantages such  as  analysis  cspsbility  and  natural  representation  of  concurrency,  but 
tbe  Petri-net  is  too  primitive  to  represent  large-scale  software  systems.  It  does  not 


support  control  and  data  abstraction  and  information  hiding.  It  is  very  complex  and 
dilficult  to  understand  tbe  whole  system  structure  when  the  Petri-net  method  is  used 
in  large-scale  software  design.  Due  to  these  undesirable  aspects  of  this  spproach,  it 
is  not  suitable  to  be  used  in  ADS  software  development. 

Object-oriented  design  is  a design  method  based  on  the  concept  of  classes  and 
objects.  It  supports  principles  of  softvraic  engineering  such  ss  information  hiding. 


modulanly,  weak  coupling  and  strong  cohesion,  reusability,  abstraction  and  exten- 
sibility [9,  59,  61].  Booch  (9]  introduced  object-oriented  design  and  Vau,  et  al.  [61] 
introduced  a new  object-oriented  design  for  parallel  processing  systems.  The  cbar- 
acteristics  of  object-oriented  design  are  desirable  in  ADS  software  development  to 
support  its  on-line  maintmnability  and  on-line  expandability.  A software  system  can 
be  considered  a set  of  cooperating  objects,  which  are  natural  units  for  parallelism  [61], 
and  the  organiaation  of  objects  naturally  reflects  the  structure  of  many  distributed 
computing  applications.  Object-oriented  design  has  been  successful  in  simplifying  the 
design,  implefxientation  and  maintenance  of  software  for  dynamically  varying  appli- 
cations [10).  Tbe  data  and  program  encapsulatioo  provided  by  object-oriented  design 
allows  software  to  be  adapted  easily  to  changing  environments.  Booeb’s  methodol- 
ogy [9|  derives  from  a textual  specification.  Objects  are  identified  from  the  nouns 
and  object  methods  are  identified  from  the  verbs  of  textual  specification.  It  vrorks 
well  when  the  specification  is  described  with  a few  paragraphs.  However,  when  the 
requirements  are  large  and  complex,  it  is  not  an  easy  task.  It  lacks  a systematic 
way  to  identify  objects  and  methods  aod  it  does  not  give  an  explicit  method  for  hi- 
crarchical  decomposition  of  objects,  which  Is  needed  for  any  sisable  system.  HOOD 
[22]  and  GOOD  [47]  are  object-oriented  design  methods  combined  with  hierarchical 
decomposition  methods.  Wasserman  proposed  the  OOSD  design  notation  to  allow 
designers  lo  follow  either  a functional  or  an  tdiject-orienled  approach  [55].  However, 
no  object-oriented  design  method  for  ADS  software  has  been  developed.  Current 
object-oriented  design  methods  do  not  fully  address  the  characteristics  of  ADS  soft- 


In  this  dissertation  following  aspects  are  assumed: 


• the  enviroDment  is  a loc&l  arcA 

• the  network  eoviroDroent  aupporte  message  broadenating  logically; 

• broadcaatiog  is  an  atomic  operation  in  the  system; 

• the  distributed  processors  can  be  heterogeneous; 

• parallel  processors  are  not  considered. 

Id  this  dissertation,  the  scope  ol  the  application  area  is  the  data  Bow  type  of 
application.  The  data  Bow  diagram  is  excellent  to  represent  that  type  of  application 
in  the  requirement  analysis  phase.  Our  transformation  approach  can  be  applied  to 
the  real  problems,  even  though  we  do  not  develop  the  decomposition  method  in 
this  dissertation.  We  can  decompose  the  data-fiow  diagram  intuitively  with  help 
from  some  mathematical  analysis  methods,  such  as  McCabe’s  DFD  timing  analysis 
method  [35]. 


CHAPTEaa 

SOFTWARE  DEVELOPMENT  FOR  ADS 

[n  this  chapter,  the  software  developmeot  approach  for  ADSs  is  preseoled. 

The  approach  consists  of: 

s software  requirement  aoaJysis  phase; 

• decomposition  phase; 

• veriRcatioo  and  analysis  phase; 

• partitioning  and  allocation  phase; 

• testing  phase. 

The  output  of  each  phase  becomes  the  input  of  the  next  phase.  The  approach 
is  not  a simple  linear  process.  It  has  iterations  between  adjacent  phases.  Because 
ADS  software  reqniren  on-line  expandability  and  on-line  maintainability,  the  software 
is  evolved  endlessly  through  the  whole  system  life  time.  So,  iterations  of  the  devel- 
opment activities  are  naturally  required.  Figure  3.1  shows  those  phases  and  their 
relationship  in  the  ADS  software  development. 

From  the  viewpoint  of  the  ADS,  the  data  flow  type  of  software  is  much  more 
suitable  for  oo.line  properties  than  the  client/server  type  of  software  (3i|.  It  is  also 
much  mope  effective  way  to  maximise  the  utilisation  of  the  broadcasting  capability  in 
ADS  environments.  Data  flow  diagrams  (DFDs)  are  excellent  for  describing  the  flow 
24 
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of  d»la  to  and  from  the  data  proceaaea.  We  use  the  data  flow  diagram  aa  primary 
model  for  the  requirement  analyaia  phase  for  this  reason.  Besides  the  data  Bow 
diagram,  we  also  use  a data  dictionary  and  a state  transition  diagram  to  enhance 
the  completeness  and  expressiveness  in  this  phase.  The  data  dictionary  contains 
details  missing  from  data  flow  diagrams.  It  defines  data  flows  and  data  stores  and 
the  meaning  of  various  names.  The  state  transition  diagram  gives  more  detailed 
information  about  data  processes  and  control  prosses  io  a data  flow  diagram. 

In  the  requirement  analysis  phase,  the  ptimsry  task  is  to  identify  the  data  flows 
from  the  sources  to  the  sinks.  One  sspect  which  is  not  generally  considered  in  the 
cooveotionaJ  software  requirement  analysis  methodologies  [16}  is  the  ondine  expand* 
ability.  In  the  requirement  analysis  phase  for  ADS  application  software  development, 
we  need  to  identify  the  data  which  will  also  be  used  in  future  system  expansion.  One 
way  to  represent  future  expansion  of  system  in  the  requirement  analysis  models  is 
to  use  the  notation  of  a dummy  component  io  the  data  Bow  diagram.  In  Figure 
3.2,  we  show  the  part  of  data  flow  diagram  which  includes  a dummy  component 
for  the  future  system  expansion.  The  box  with  dotted  lines  represents  the  dummy 
component  which  is  not  required  to  the  loiliaJ  development  stage  but  in  the  future 
expansion.  The  box  E will  be  converted  into  the  complete  DPD  when  the  expansion 
of  the  correspondlog  part  of  the  system  is  decided  in  the  future.  It  may  be  impossible 
to  identify  aU  data  completely  for  the  future  system  expansion,  but  we  can  ideotify 
some  of  them  at  the  initial  software  development  stage.  By  identifying  the  data  for 
the  future  expansion,  we  can  develop  ADS  application  software  that  is  easily  on-line 
expandable.  If  a new  module,  which  was  not  identifled  in  the  initial  development 
slage,  needs  to  be  added  into  the  existing  software  system,  then  currently  existing 
modules  may  need  to  be  modified.  So,  the  on-line  expansion  In  the  latter  case  is  more 
complex  than  in  the  former  case.  We  use  a DFD  in  which  control  flow  and  control 
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pnceu  tK  represented.  It  is  similar  to  the  Ward's  data  Sow  diagram  (54|  except 
that  the  dummy  component  notation. 

In  the  decomposition  phase,  the  system  is  decomposed  into  a set  of  modules.  We 
use  the  data  Bow  diagram  as  the  input  of  the  decomposition  stage.  The  output  of 
decomposition  stage  is  a decomposed  data  flow  diagram.  Closely  related  processes 
and  data  stores  are  grouped  together.  Each  decomposed  group  is  a subset  of  tbs 
data  flow  diagram  of  Ibe  whole  system.  Each  data  flow  edge  connecting  two  subsets 
becomes  the  interface  of  those  subsets.  Tbe  criteria  of  this  stage  are  parallelism, 
communication  and  performance. 

The  decomposed  data  flow  diagram  is  transformed  into  the  module  model  that 
is  based  on  our  computation  mcxlel.  The  our  transformation  method  is  similar  to 
Alabiso’i  |3J  and  ToeteneTs  {Slj  approaches.  In  [3)  Che  DPD  is  transformed  ioto 
tbe  object  model  that  is  based  oo  Sma]halk*SO  [23].  In  [51],  tbe  DFD  construct  is 
converted  into  the  equivalent  VDM  notations  [14].  Both  approaches  are  too  general  to 
be  applied  into  tbe  ADS  applicatioo  aoftware  design.  The  activation  relation  between 
data  processes  is  introduced  for  establishing  tbe  module  interfaces.  Data  flow  type  of 
a remote  object  method — >0De  way  communication  based  object  method  invocation, 
and  one-to-many  object  method  invocation  are  supported  in  the  module  model.  With 
these  additional  features,  we  can  effectively  design  ADS  application  software. 

The  high'level  design  description  language  that  is  based  on  our  computation 
model  is  used  to  represent  the  design.  That  high-level  design  description  language 
is  translated  into  skeleton  of  extended  C-l-f  code  io  the  implementation  phase.  By 
using  a translator  the  extended  C-b-f  codes  are  translated  intoC-f -f  codes  including 
some  system  calls  for  interfacing  the  ADS  environment.  Because  the  representation 
models  and  design  description  language  are  based  on  the  same  computation  model. 
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I)  Before  synem  erpuuloo 


b)  A/ier  sysum  expand 


Figure  3.2.  The  repr 


we  can  avoid  the  problem  of  the  semantic  gaps  between  the  consequent  phases  of 
ADS  software  development. 

Id  the  verification  and  analysis  phase  the  correctness  of  software  design  is  checked. 
The  design  specihcatioD  (written  in  a highdevel  design  description  language)  is  trans* 
formed  to  the  semantically  equivalent  Petri-net  model.  By  using  the  Petri  net,  we 
detect  design  errors,  such  as  dead-lock. 

In  the  partitioning  and  allocation  phase,  software  modules  are  grouped  together 
and  assigned  into  each  processor.  In  this  phase,  the  replication  of  modules,  location 
of  physical  resource  and  the  processing  capability  of  each  processor  are  considered. 

In  the  testing  phase,  unit  testing:  module  level  and  object  level,  and  integration 
testing  are  performed.  In  ADS  environment  this  testing  is  done  not  only  at  the  initial 
software  development  stage,  but  also  during  the  whole  life  time  of  the  system,  i.e., 
on-line  testing.  Visualication  tools  nre  used  in  this  phase.  The  visual  environment 
shows  BIT  view,  EXT  view.  Snapshot  of  ADF^  and  structure  of  the  program  tested. 


'BIT.  EXT  sod  AOF  sie  deRoed  in  |3SJ 


FEATURES  OF  THE  COMPUTATION  MODEL 


The  computation  model  ia  based  on  an  object-oriented  concept.  An  object  is 
a fundamental  encapaulation  unit  in  this  model.  Object-oriented  software  systems 
have  desirable  features  for  ADS  software  such  as  expandability^  modiRabUity,  and 
modularity.  The  property  of  modularity  makes  software  decomposable  into  a set  of 
cohesive  and  loosely  coupled  components.  In  the  computation  model,  a program  of 
ADS  is  represented  as  a Rnite  set  of  cooperating  modules.  Each  module  has  its  own 
processing  power(control  thread),  and  it  has  its  local  objects.  The  following  is  the 
structure  of  the  computation  model. 

P;  an  ADS  application  program 
M,:  module! 

M,  € P,  where  i = l..n 

Mi  = Infi  + OBJ,  + B,, 

where  Infi  is  an  interface  of  the  module  Mi, 

OBJi  is  a set  of  object  class  deRnitions  and 
Bi  is  a body  of  Af, 

Infi  = Int,  *f  Exi, 

where  Im,  is  the  set  of  import  object  methods 
and  Ex,  is  the  set  of  export  object  methods. 

B,  = Soi  + Sp,, 

where  Stx,  is  the  set  of  statements  for  object 
instantiation  and  Sp,  is  a process  description 
for  the  module  Mi. 
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Couceptuaily,  each  module  ie  executed  by  Us  owe  abstract  maebtee.  The  ab- 
stract machiee  executes  its  own  task  (procedure  defined  in  the  body  of  a module} 
as  well  as  receives  and  sends  messages.  A message  includes  informatioo  oo  remote 
object  method  invocatioo  or  the  result  of  the  remote  object  method  invocation.  The 
structure  of  an  abstract  maebioe  that  executes  a program  baaed  on  the  computation 
model  is  shown  in  Figure  4.1.  There  are  two  different  types  of  message  queues  in 
the  abstract  machine.  One  is  for  the  method  invocation  from  other  modules  and  the 
other  is  for  recetving  the  results  of  remote  object  methods.  Solid  lines  in  the  fig- 
ure denerte  asynchronous  cootrol  and  data  hows  and  dotted  lines  denote  synchronous 
control  and  data  flows. 

The  following  are  major  features  of  our  model: 

a)  object-oriented;  object  and  class  concepts  are  bases  of  our  model; 

bj  two-level  encapsulation  units:  module  and  object  levels; 

e)  the  guard  of  method  to  support  synchronisation  belween  concurrent  modules; 

dj  asyzichrooous  remote  object  method  invocation  by  the  broadcasting  message; 

e)  synchronous  local  object  method  invocation; 

D incorporation  of  a data  flow  concept  into  an  object-oriented  coocept; 

g)  preservation  of  serialisation  in  remote  object  method  lovocations; 

h)  lopcal  locational  transparency  in  a remote  object  method  invocation; 

i)  exception  handling  in  a remote  object  method  invocation- 
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Two-levcl  eoc»paul«tioii  units,  incorporntion  of  t dntnflow  concept  into  an  object- 
oriented  concept,  and  logical  locational  tiansparency  in  a remote  object  method 
iovocatioo  are  the  unique  features  of  our  model. 


when  they  need  tocommunicateor  tobe  ayochronized  with  each  other.  In  distributed 
object-oriented  programming  systems,  objects  are  the  basic  process  units.  If  a sys- 
tem has  different  semantics  of  object  method  invocation  with  regard  to  the  target 
object's  location,  this  adds  complexity  to  the  program  design  and  implementation. 
Fbrthermore,  it  may  lead  to  subtle  errors.  So,  identical  semantics  of  local  and  remote 
object  methods  are  much  more  desirable  in  distributed  object-oriented  programmiog 
systems.  For  this  reason,  every  method  iovocatioo  io  ADS  environments  should  be 
based  on  asyochronous  broadcast  message  passing.  However,  the  broadcrastiog  crun- 
municatioD  mechanism  is  too  expensive  when  the  objects  are  located  on  the  same 
processor.  When  interacting  objects’  grain  sixes  are  considerably  small  in  an  ADS 
application  program,  it  will  introduce  severe  communication  overhead.  It  will  also 
inciease  the  sise  of  the  table  in  each  procesaor  to  manage  communication  and  con- 
tribute to  degrade  the  whole  lystem'i  performance.  To  overcome  these  undesirable 
situations,  two  different  levels  of  encepsulation  units  are  introduced — a coarse  grain 
encapsulation  unit  r:allcd  module  and  medium  grain  (or  line  grain)  encapsulation 
unit  called  ohjecL  Therefore,  interaction  between  modules  (remote  object  method 
invocation)  is  done  by  the  asynchronous  message  passing  method,  and  intra-module 


operation  (local  object  method  invocation)  is  done  by  a synchronous  way.  The  de- 
signer decomposes  application  software  into  a set  of  modules,  based  on  the  criteria, 
such  as  performance.  In  hgure  4.2,  two-level  encapsulation  in  our  model  is  shown. 
S1.1  Module 

The  construct  of  a module  in  the  computation  model  for  ADS  software  devel- 
opment  is  similar  to  those  of  modules  used  in  conventional  programming  languages 
such  as  Modula-2  [56].  However,  properties  of  the  module  in  the  computation  model 
are  different  from  those  of  module  in  Modula-2.  No  module  is  a subset  of  another 
module.  It  cannot  be  included  in  another  module.  Every  module  is  an  independently 
dc6ned  unit.  It  is  an  autonomous  unit  from  the  view  point  of  ADS.  It  consists  of 
three  parts;  interfaces  to  communicate  to  other  modules,  class  definitioos  for  its  own 
local  object,  and  its  body. 

The  module  has  its  own  cootrol  threads  when  its  body  has  a procedure  definition 
part.  In  the  body  of  a module,  objects  are  instantiated  and  the  processing  activity 
of  the  module  is  defined.  If  the  module  has  its  own  control  thread,  then  this  is  called 
an  ocline  modtJe.  When  it  does  not  have  its  procedure  definition  in  its  body,  this  is 
called  a possioe  tnodufe.  A passive  module  is  like  a server  in  the  client/server  model 
or  a service  agency  in  the  Actor  model.  The  active  module  is  always  active  except 
when  its  operation  is  suspended  to  synchronize  with  other  modules. 

The  interface  of  a module  consists  of  two  parts: the  definitions  of  the  export  object 
methods  and  the  definition  of  the  import  object  methods.  Only  the  export  object 
method  is  visible  from  the  outside  of  that  module.  A module  communicates  to  other 
module*  by  invoking  its  import  object  method.  Invocation  of  an  invisible  object 
method,  which  is  defioed  as  a local  object  method  in  other  modules,  is  not  avail- 
able. By  this  mechanism.softwareengineering  principles,  such  as  data  and  operation 


Module-level 
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encApaulation,  information  hiding,  modul&nty,  and  abstraction  arc  supported  at  a 
coarae-grain  levd. 

A local  object  is  an  object  whose  claaa  is  defined  in  the  same  module.  The  local 
object  method  invocation;  method  invocation  of  object  in  a same  module  is  syo. 
ebronoua  and  the  same  as  that  of  conventional  sequential  object-oriented  languages. 
The  unit  of  a process  allocated  into  each  processor  is  the  module  in  our  computation 
model.  So,  asynchronous  local  method  invocation  does  oot  have  any  advantage  over 

A remote  object  la  referred  to  as  object  whose  class  is  dehoed  in  another  module. 
The  remote  object  method  iovocation  is  based  on  an  asynchronous  broadcasting 
commuokatioo  mechaoiam.  A module  can  lovoke  another  modules'  export  object 
methods  simultaneously  when  those  modules  have  an  identical  name  of  export  object 
and  method  in  their  interface  dehnition.  The  implementation  of  remote  module 
object  method  invocation  is  done  by  broadcasting  the  message  to  every  module. 
Tbe  message  consists  of  actual  parameters  for  the  method  invocation  and  n content 
code  uniquely  assigned  to  that  object  method.  It  does  not  contnio  nny  destination 
module  s locntion  inforrantion.  Therefore,  we  don't  need  to  be  concerned  about  tbe 
location  or  reference  of  the  target  object,  ie.,  locational  transparency  is  supported. 
We  can  replicate  the  module  and  invoke  the  replicated  module's  object  methods 
simultaneously  by  using  a single  command. 

The  textual  formalof  a module  in  our  compulation  model  is  shown  io  Figure  4.3. 
We  will  use  the  symbol  (’I”)  as  a construct  for  n remote  object  method  invocation.  In 
figure  4.4,  graphical  representations  of  a module  is  shown.  The  arrow  head  symbols 
represent  export  and  imporl  objects'  methods.  An  outgoing  directed  arrow  head 
impliesaa  export  object  method,  and  an  incoming  directed  arrow  bead  symbol  implie* 
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Mo<lule  m^uU'name: 

import  object  method:  otj-nomc.'meUiod-name 
(pdreme(er‘/u() 

export  object  method:  ebj~name!metk9d'name 
{panmrUr-list) 

clue  definition 

lut  of  class  definition 


body  of  Module 

object  ifutenliolioe  and  description  of  process 
end  Module  rnodide*ncmc 


Figure  4.3.  Textual  format  of  a module 


^ ObjA.puUinl) 


Class  denniiloo 


Oass  denniiioo 


Figure  4.4.  Graphical  notation  of  a module 


underataodability  of  wbolo  software  system  structure  and  its  function, 
a 1.2  Object  and  Class 

A class  is  a template  for  a set  of  objects  having  similar  behavior.  An  object  is 
an  instance  of  a class.  A class  deHnilion  consists  of  class  name,  yuanf  statement, 
composition  of  local  data,  and  its  methods.  Inheritance  is  supported  in  the  com- 
putation model.  C-t-4-  construct  is  used  to  explain  the  features  of  the  computation 
model.  It  extends  the  class  definition  constructs  of  C-f-1-  to  define  a class  in  the  ADS 
software  design  process.  The  guard  statement  in  the  definition  of  a class  to  support 
synchrooisalioE  of  shared  resource  access  is  added.  Ao  example  of  a class  definition 
for  a bounded  buffer  is  shown  in  figure  4.5. 

All  objects  in  the  computation  model  are  passive  objects;  i.e.  they  are  activated 
only  when  modules  invoke  them.  The  puilic  methods  are  visible  to  the  outside  of 
that  object,  hut  the  phvali  methods  are  Dot  visible  to  the  outside  of  the  object. 
Therefore,  the  private  methods  are  accessible  only  from  the  Iniide  of  the  object. 
For  example,  the  private  method  next  can  be  accessed  by  the  methods  tiller  and 
lenw  of  class  iaffer.  An  export  object  method  invocation  from  the  inside  of  the  same 
module  is  not  permitted.  Invocation  of  export  object  method  is  possible  only  from  the 
outside  of  the  module.  By  this  restriclion,  possible  software  design  or  programming 
errors  caused  by  the  wrong  usage  of  semantically  different  method  invocation  can  be 
prevented;  i.e.,8yocbronons  method  ipvocation  and  asynchronous  method  invocation. 


The  methods  defined  in  each  shared  object  may  require  some  synchroniiation 
meebanisms.  For  example,  the  method  enter  of  the  class  injer  can  be  executed  only 
when  the  buffer  is  not  full.  When  the  buffet  is  fuU,  the  process  which  Invokes  the 


Module  buffer-mcxiule; 

export  object  method:  buHerAlenter(chor), 
bulferA!leeve(cliu): 

class  buffer  { 

bufferQ  { size  = 100;  front  — rear  = 0;} 

enter(char); 

leave(cbar}; 

char  buf]100|: 

iat  next(int  i)  { return  (i-fl)  % size;} 

buffer:;eoter(charx)  { 
guard  ( oext(rear)  !=  front ); 
bullreari  = x;  rear  = next(rear); 


buffer::leave(char  x)  { 

guard  ( front  !ss  rear  ); 

lot  X = buf}frontj;  front  = next  (front); 

Body  of  Module 

buffer  bufferA  /•  object  instantiation  */ 


end  Module  buffer-module 


Figure  4.5.  Class  definition  of  the  module  for  a bounded  buffer 


oielhod  enter  must  be  suspended  until  the  condition  is  satisfied.  Tb  support  syn- 
chronisation of  the  shared  data  accesses  amoog  concurrent  processes,  semaphore  or 
message  queue  is  used  in  Unix  systems.  However,  they  are  primitive  to  use  directly  in 
software  design  and  implementation.  Usage  of  those  synchronization  constructs  may 
cause  to  increase  the  complexity,  to  decrease  the  understandability,  and  to  introduce 
unexpected  errors.  To  reduce  the  occurrence  possibilities  of  these  undesirable  situa- 
tions, a guard  construct,  high  level  abstraction  to  support  synchronisation  of  access 
to  the  shared  object  is  introduced.  The  guard  construct  is  originally  introduced  by 
Dijkslra  [17]  and  used  in  CSP  [27]. 

If  the  result  of  guard  expression  is  true,  then  the  object  method  is  invoked.  If  the 
result  of  guard  expreasion  is  false,  then  the  object  method  invocation  is  suspended. 
If  the  process  of  a module  invokes  its  local  object  method  and  the  result  of  guard 
expression  is  false,  then  the  process  is  blocked.  After  the  condition  is  satisfied,  the 
suspended  process  is  resumed;  i.e.,  the  method  is  iovoleed. 


There  are  two  types  of  objects  in  the  model.  One  is  a local  object  and  the  other 
is  a remote  object.  The  local  object  is  not  visible  from  the  outside  of  its  module- 
The  remote  object  is  deHned  for  the  interactions  among  module. 


The  invocation  of  a local  object  method  is  permitted  only  inside  of  its  own  module. 
The  method  invocation  is  synchronous.  A process  invoking  the  method  waits  until 
the  method  is  completely  executed.  After  the  execution  of  the  method  is  completed, 
the  process  can  continue  Its  operation.  It  is  similar  to  a subroutine  call  in  imperative 
programming  languages. 


<■3  Object  Method  Invocation 


2 Remote  Obit 


lnvoc*lioD 


Modules  io  so  ADS  software  system  cooperate  with  each  other  by  invoking  remote 
object  methods.  Invocatioo  of  a remote  object  method  is  performed  by  a broadcasting 
commuoicatioD  mechanism. 

There  are  two  types  of  remote  object  method  invocation  based  on  its  data  and 
control  flow  directions.  They  are  one*way  type  object  method  invocation  and  two*  way 
type  method  invocatioo.  When  the  source  module  (a  module  which  iovokes  another 
module’s  object  method}  iovokes  a remote  object  method,  and  it  needs  no  result 
of  the  invocation,  i.e.,  it  simply  sends  data  or  control  information  to  a destination 
module,  then  this  is  called  a one-way  type.  If  the  result  of  the  methrrd  invocation 
is  required  to  tbe  source  module,  theu  this  is  called  a two-way  type.  The  type  of  a 
remote  object  methrxl  invocation  is  distinguished  by  tbe  parameters  of  that  object 
method  implicitly.  If  a method  baa  some  output  parameters,  then  it  is  included  in 
tbe  class  of  two-way  type.  If  a method  has  only  input  parameters  or  no  parameters, 
then  it  is  included  in  a class  of  ooe-way  type. 

4.3.3  Exception  Handline  for  Remote  Object  Method  Invocation 

In  general,  it  ia  not  guaranteed  that  a process  invoking  a remote  object  method 
receives  result  data  when  the  process  is  ready  to  access  the  result  data.  If  there 
is  a fatal  accident,  surdt  as  disconnection  of  a network  or  shutdown  of  a datination 
processor,  then  a process  invoking  a remote  object  method  may  be  suspended  forever. 
This  is  not  a desirable  situation  in  the  ADS  environments.  To  avoid  this  problem, 
an  exception  handling  mechanism  tor  remote  object  method  invocation  is  supported 
io  the  computation  model.  This  exception  handling  mechanism  is  supported  only 
in  the  two-way  type  remote  object  method  invocation,  because  in  an  one-way  type 
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method  iovocatiOD,  an  iovokio^  process  is  not  effected  by  the  result  of  the  method 

When  e remote  object  method  iavocation  is  defined,  the  exception  hudliag  rou- 
tine for  this  remote  object  method  invocetion  is  also  deliaed.  If  the  result  is  not 
recdved  by  the  invoking  process  when  it  is  ready  to  access  the  result  data,  the  prede- 
fined exception  handling  routine  is  executed.  This  exception  handling  supports  the 
fault  tolerance  at  the  application  level. 

Examples  of  modules  for  a producer  and  a consumer  is  shown  in  figure  4.6.  In 
the  definition  of  the  module  coos*module,  a statement  for  a remote  object  method 
invocation  is  shown  with  the  exception  handling  statement  retry.  In  this  case,  the 
output  parameter  item  is  accessed  again  and  again  until  the  actual  value  is  arrived. 
We  uae  the  symbol  as  tbe  construct  of  exception  handling. 

4.3.4  Locical  locational  ’tYansnarencv  in  Remote  Object  Method  Invecalion 
The  locational  transparency  is  classified  into  two  categories,  physical  location 
transparency  and  logical  location  transparency. 

DeSnition  X.S.I  physicsl location  fmnsporency 

//  a female  oiijecl  method  iavocalion  does  no(  refuire  the  in/armation  about  the  des- 
tination module 'o  pAysienf  location,  if  is  called  phyeicalljt  locational  transparent. 

Deltnition  J.S.S  logical  facalianof  transparency 

1/  a remote  object  method  invocation  does  not  require  the  information  ohoul  the  dea- 
linniion  module's  nome  or  identijicalion,  il  is  called  loealionally  Iranaperenl. 

The  physical  location  transparency  h supported  by  the  communication  systems. 
It  is  the  property  of  an  ADS  and  its  system  software.  Many  object-oriented  or  object- 
based  distributed  systems,  such  as  tbe  Emerald  |32]  and  the  Cloud  (13),  support  tbe 


Module  prod'iuodule: 

Import  object  method:  bufrerAlenter(cli&r); 


Body  of  Module 


bufferA!eotet(produce^&r()); 
end  Module  prod-module 
Module  coai-module: 

import  object  method:  bulTerA!loeve(cher}; 


Body  of  Module 
lot  item,x;  . 

buRerA!le«ve(ilem):retry; 


end  Module  cona-module 


Figure  4.6.  Example  of  modules  for  a producer  d: 


phy«c»l  locitioB  transparency  in  « teniol«  object  method  invocation.  The  goal  of  the 
physical  location  transparency  in  those  systems  is  to  make  a programmer  free  from 
concern  about  the  low-level  details  and  system  architecture  aspecU-  In  an  ADS,  it  is 
also  supported  to  pve  the  on-line  properties  of  distributed  software  modules. 

The  lojcal  locational  transparency  is  an  aspect  at  the  programming  level.  It 
should  also  be  supported  to  maaimise  the  on-line  properties  of  distributed  software 
modules  in  the  ADS-  If  the  module  name  or  module  identification  is  required  for  the 
interaction  between  distributed  modules,  it  is  difficult  to  have  on-line  expandability 
of  application  software  modules-  The  computation  model  bai  Ihe  logical  locational 
transparency  in  remote  object  method  invocations.  Only  the  remote  object  name  and 
its  method  are  required  to  interact  with  other  modules.  In  case  that  a new  extended 
module  is  a destination,  then  the  extension  of  that  module  does  not  interfere  with 
the  modules  which  already  exist  and  are  activated. 

Data  Flow  Concept 

The  computation  model  has  an  on-line  expansion  property  by  the  incorporation 
of  a data  fiow  model  into  an  object  oriented  model.  In  general,  the  data  flow  com- 
putatioD  model  is  at  the  fine  grain  level,  Oo  the  other  band,  the  data  Sow  in  the 
computation  model  is  at  the  coarse  grain  (module)  level.  In  the  data  flow  computa- 
tion model,  each  processing  component  is  activated  by  accepting  a token  (or  input 
data).  After  accepting  the  token,  the  processing  component  executes  its  operation 
and  generates  tokeus  (output  data)  for  the  next  stage  of  components. 

Let’s  assume  that  two  processing  components  A and  B of  a data  flow  model  are 

The  control  thread  of  the  component  B does  not  affect  the  slate  of  the  component 


45 


A.  Eveo  though  a uew  compooent  C is  added  as  a next  component  of  B,  the  states 
of  componenls  A and  B are  not  affected  by  this  expansion. 

In  the  model,  a processing  component  is  a module.  The  one-way  type  remote 
object  method  lovocatioo  supports  the  data  Sow  paradigm  in  our  model.  By  this 
property,  a new  module  can  be  added  into  a current  system  at  run  time  without 
interference  from  the  operations  of  another  modules.  In  a design  level,  a dummy 
remote  object  method  may  be  predehoed  as  an  import  object  method  iu  a module  for 
the  future  expansion.  A new  module  that  has  an  export  object  method  corresponding 
to  the  predefined  dummy  remote  object  method  can  be  added  Into  the  system  later.  In 


the  new  module.  Even  though  it  is  possible  to  achieve  tbe  on-line  expansion  without 
a predehoed  dummy  object  method,  it  may  introduce  tbe  modification  problem  of 
the  existing  software  modules. 


SEMANTICS  OF  OBJECT  METHOD  INVOCATIONS 


To  explftia  behftvior  of  object  method  invocatioiic  in  the  computation  model 
formally,  an  operational  demaotics  technique  ie  used.  The  operational  semantics  in 
this  dissertation  is  based  on  a transition  system.  The  transition  system  technique 
was  introduced  by  Henuessy  and  Plotkin  [26].  America  [6, 5]  and  Agha  |2]  have  used 
this  technique  to  formalise  behavior  of  their  computation  models. 

A (ronatlion  system  T is  givtn  hy 
r * ( Conf,  X,  ), 

uAere  Conf  is  a set  oj  eoeififfuniions  and  Xr  is  a set  of  transUion  rtIcUons. 

tions  between  configurations.  A configuration  is  the  description  of  system  status  at 
a specific  moment  of  program  execution. 


gefinitien  S.O.t  liunsifion  relsUon 

A set  oj  Iransilion  relalion  Xr  is  yiuen  hy 

Xt  C Con/  X Con] , 

uAere  Con]  is  a set  o]  configvTotions. 

A lypicol  eJement  -•  o/X.  is  a Unary  reJotian  ielveen  eonfiynmlions. 

lb  explain  the  semantics  of  object  method  invocations,  a primitive  programming 
language  LADS  will  be  defined,  based  on  our  computation  model. 


r 
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p»/iiiili<iB  S.O.S  SlaUnnU 

JTi<  set  of  statements  LADSst  ts  defined  bi/ 

, € LADSs,, 

• ;;s  e I 0.1  I o!c  I guord(e)  | p,  \ wait  [ idle  | return. 


ject  method  invocation  itatement,  and  a remote  object  invocation  rtateznent.  The 
statement  o.t  denotes  a local  method  invocation.  The  statement  o and  I represent 
an  object  and  its  method  respectively.  The  statement  o!r  implies  a remote  object 
metbod  invocatioD.  The  symbol  r is  the  method  name  of  object  o.  Referencing  the 
output  parameterof  a remote  object  method  invocation  is  considered  here  as  a state- 


object  method  after  the  method  is  invoiced.  Additional  statements,  wait,  idle,  and 
return  are  used  to  explain  the  state  of  each  process  moniog  on  an  abstract  machine 
based  on  the  computation  model.  Also,  dummy  object-name  6 and  method-name 
md  arc  used  in  order  to  define  the  body  statements  of  each  module  in  LADS.  With 
these  dummy  names,  both  body  and  object  statements  can  be  identictaljy  treated  in 
our  formal  definition  of  a labelled  statement. 


DeRnition  S.O.J  Label 

The  set  of  labels  Suw  is  defined  by 

Suui  - Sun  X (Sv.sj  * {d}}  x [Sn„s  +■  (md)}, 

Sn„  is  the  eel  of  modules' names  and  Sh*,  is  the  set  of  objeeU'  netnes. 


r 
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Fbr  <ODv«oiencc,  we  wiU  use  eymbol  a ee  e lypicel  element  of  Sum- 
Oijk  = ( »;•  ). 

where  Oj  and  mde  ere  typical  elements  of  Ssm,  [Sfietj  + {6}}  and  + 

{mdj)  reepectively. 

OiOO  ^ (wii.o.W) 

So,  OTiOO  deootes  the  body  of  module  m*. 


nf.Rnition  5.0.5  Labelled  elatement 

The  eel  oj  labelled  statemenle  LADSu,  is  gioen  by 

LADSisi  ~ X LADSsi- 


Deffntiton  5.0,6  Labelled  measage  ^eue  stole 

The  set  of  labelled  message  gveue  states  LADSlqs  ^ pioen  by 

LADSiqs  = Snw,  ^ SseSj  a Ssms  a Q, 

The  element  q is  a typical  elcmealof  Q.  The  element  q (=  has  the 

following  functions: 

iiuerl(nu,  (m,,ms,...m,»  - {ntj.tns, 
defele«m,,mj,...m,))  = 

no(emply({m,,mj,...m.))  = | (n  = oj 

n<rfemply(//usA(q))  = false 
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Qf.finitian  5.0.7  State 

The  set  of  slates  S is  defined  by 

s = IVar  ValJ  x LADSuys. 


The  element  e is  s typiceJ  element  of  the  eet  5 . The  dement  <r  consists  of  two 
componeots,  Oi  and  0’s:  a — The  element  Oj  denotes  the  state  (instant 

value)  of  each  variable  and  os  denotes  the  state  of  each  message  queue  for  a remote 
object  method  iovocatioo. 

DeSnilion  5.0.8  ConfptnUon 

The  set  of  ean^yaration  Conf  is  given  by 

Conf  = p{LADStst)  X 5 X Prog, 

uAere  p[LADSis,]  is  the  power  set  of  the  set  LADSist  and  Prog  is  a program  in 
LADS. 


A typical  element  c of  set  Conf  consists  of  three  componeots,  i^.  c — (£5,  a,  P} 
The  first  component  LS  is  a finite  set  of  labelled  slatemeoti  which  are  defined  as  a 
part  of  the  body  definition  of  each  module  or  a part  of  the  object  method  definition, 
that  is,  £5=  { (m,.oo,md.),..(m„Oj,md4)  ..,(mi,o,„,m<t.)  }. 

The  componenU  m„  o,  and  mdj  are  a module  name,  an  object  name,  and  a method 
name  respectively.  P is  a program  that  is  used  for  looking  up  the  definition  of  each 
method  and  each  active  module's  body. 

Each  name  of  modules  and  objects  is  unique  in  the  program  domain.  Different  mod- 

ules  can  have  the  same  namea  of  object  and  method,  i.e  for  import  object  methods. 


So,  the  following  relation  ie  eetabliabed: 

where  (»  jS  i'A  {Tn,-,Oj,mdi)  € Suu  g ) 

h {oj,  mdt)  g {{o,m<l}  | o is  a remote  object  and  mdi»  an  exported  method  io  P}. 

5,1  Local  Ohiect  Method 

The  primary  operational  sequences  of  a local  object  method  invocation  are  method 
invocation,  execution  of  the  guard  staterrrent  of  that  method,  execution  of  each  state- 
ment in  the  method  definition,  and  return  to  the  calling  process. 

5.1.1  Method  Invocation 

The  following  transition  relation  denotes  the  semantics  of  a local  object  method 
invocation. 

{LS  U {(a,oo,o,.mj),{Q,q,id/e)),o,/-) 

{LS  U {{oi«i,wjut(oii,)),(<Sig,juard(e)»,rT',P), 
where  o^  = local  object  io  module  m,, 

(<ri,<rs>,  ff'  = (rri'.ffj),  <r,.  = o,  {u„/p„). 

ri./.)w«{;“  zi: 

The  parameter  Pi,  is  an  input  parameter  of  the  method  and  o„  is  its  corresponding 
actual  value.  We  use  a{v/p]  to  denote  the  state  that  is  same  as  ir  except  that  the 
actual  value  of  p is  v.  When  a local  object  method  is  invoked,  the  guard  statement 
of  the  method  m,-  is  executed  and  the  calling  process  wails  until  the  execution  of  the 
method  is  finished.  Therefore,  the  local  method  invocation  is  synchronous. 


Executic 


Guifd  Stttanent 


The  followiDg  traosition  rclatioo  denotes  the  semantics  of  a guard  statement. 


{LS  U {(O(j,,yuord(e))),<r,  P) 

{LSV  {Ks,sl)),o,  P)  if  Pie]  = true 

(£5  U {Ks.JUorrfteHl.a,  P)  ifPle]  = faUe. 

where  si  is  the  first  statement  after  guard  statement  in  the  method  mds. 


?'[  ] it  a meaning  function.  Before  the  execution  of  statements  in  a method 
definition,  the  guard  expression  is  evaluated  first.  The  guard  expression  consists  of 
only  local  variables  and  constant  values.  It  is  a boolean  expression.  If  tbe  result 
of  guard  expression  is  true,  then  next  statement  is  executed.  If  the  result  is  false, 
then  the  process  continuously  evaluates  tbe  expression  until  the  result  becomes  true. 
According  to  this  transition  relation,  only  one  control  thread  1s  permitted  for  the 
execution  of  one  method.  On  the  other  hand,  dilTerent  methods  in  tbe  same  object 
can  be  executed  concurrently.  By  this  mechanism,  we  don't  need  extra  message 
queues  for  processes  bbehed  by  the  result  of  guard  expression. 

5.1.3  Return  to  the  Callins  Process 

{LS  U {(o,,»,ioaif(o,-^.s.)),  (oi^j.,rerum)),  o,P) — > 

{LS  U P). 

where  cr  = (ir,,<rs),  o'  = (<»i-.<rj).<r|.  = (r,{u./p.}. 


The  symbol  v,  is  an  actual  value  from  the  result  of  method  invocation,  and  p, 
is  an  output  parameter  of  that  method  invocation.  This  transition  relation  denotes 
that  the  calling  piocees  can  continue  executing  its  own  sUtement  after  finishing  the 
execution  of  a local  object  method.  The  labelled  statement  (oiy.*.,i<ife)  denotes  that 
the  method  mdj,v  is  ready  to  be  invoked  by  any  other  processm. 
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5.2  RgmottObifet  Method 


The  pperatiofift]  Mqueaces  of  & remote  object  method  iovocAtion  ere  method  iovo- 
cetioo,  execution  of  the  guerd  statement  of  that  method,  execution  of  each  statement 
in  the  method  definition,  and  return  of  data  for  output  parameters  in  case  of  a two> 
way  type  remote  object  invocation. 

5.2.1  Method  Invocation 

The  following  transition  relation  denotes  the  remote  object  method  invocation. 
{LS  U — • 

(iS  U {Ks,s,„».<r/,/^ 

where  cr  = (<ri,<rj),  <r'  = (oi,Or> 

oy  = oj(ins«rt(msj„i,o,(i»,„))/o^},  for  all  m,  (€  Sw„),  which  has  the  object 
method  (o,,mda}. 

This  relation  denotes  remote  object  method  invocation  that  is  based  on  an  asyn- 
chronous broadcasting  mechanism.  The  sender  continues  executing  its  next  statement 
without  wailing  for  the  result  of  the  method  invocation. 


The  following  transition  relation  denotes  the  starting  the  execution  method. 

{LS  U ((o„.,tdf«»,o,P)_ 

{IS  U 

where  ?’[nolemply(o',(Q.^,))|  = true,  o = (<r,,ir,),  ff"  = (o.,<7,), 
and  ■rj'  = <7,{*fe(e(ir,(a„,))/ct„,), 
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This  reUtioD  deoot«fl  tb&t  the  oldat  message  in  a message  queue  is  deleted  and 
a correspondiog  method  is  invoked,  i.c.,  eventually  the  guard  statement  is  evaluated 
first. 


■S.2.3  Returning  Result  Data 

The  following  transition  relation  denotes  the  semantics  of  the  returning  result 

{LS  U {{o„„return>},<r,P) — • 

(i5  U ((a„„.dIe)).o/,P). 

whereo-  = (e,,  <r,),  ir'={<T,,  Or)  <’r  = 

The  actual  output  value  of  remote  object  method  invocation  is  sent  to  the  calling 
process.  The  message  for  the  output  data  is  saved  into  a message  queue  of  the  calling 


The  following  transition  relation  denotes  the  semantics  of  the 


. returning 


{IS  U {{oioo,p,)},<r,P) 

{LS  U {(o«,s.^)),cr'.P) 

if  ^|n<rfemp(y((T,(oi^))|  = <rue 


{LS  U P) 

tf  ^natemfty{a/ai„))]  = faUe. 


When  a process  refereoces  an  output  parameter  of  a remote  object  method  in- 
vocatioD,  the  corresponding  message  queue  is  checked  whether  or  not  the  returning 
value  is  available.  If  there  is  no  available  actual  value,  the  process  executes  a pre- 
defined exception  handling  routine.  This  exception  handling  mechanism  in  a remote 
object  method  invocation  supports  fauit  tolerance  in  an  application  program  ievel. 

TAmrem  .t.P.l  In  e remote  object  mtthoi  invocation  0/  the  computation  model,  the 


Proof  of  Theorem  S.S.t  The  meoaage  seadiap  for  a remote  object  method  invocation 
is  done  bg  the  breadeasting  that  is  atomic  operation  in  the  computation  model.  A re> 
ceiver  receives  messages  with  the  some  order  as  senders  send.  Thu  order  is  preserved 
by  the  message  gveue  for  each  remote  object  method,  because  only  one  process  can 
evaluate  a guard  statement  to  execute  the  same  method  at  a time,  next  processes  for 
this  method  invocation  wait  in  a corresponding  message  gueue.  So,  the  remote  object 
invocation  is  done  on  a first  come  first  served  basis.  C 


CHAPTER  6 

INPUT  AND  OUTPUT  OF  THE  DESIGN  PHASE 
[i  this  cliapUr,  the  iapul  end  output  of  Che  ADS  loftwue  design  phaee  ere  ex- 
pleioed.  The  input  of  the  design  phase  is  the  output  of  the  requirement  analysis 

6.1  Input  of  Desien  Phase 

A data  flow  diagram,  a data  dictionary,  and  a state  transition  diagrams  are  used 
as  the  input  of  the  design  phase. 

6.1.1  Data  Flow  Diasram 

A data  flow  diagram  (DFD)  in  this  dissertation  is  composed  of  a set  of  data  flows 
and  a set  of  nodes  for  data  sources,  data  sinks,  processes,  and  data  stores. 

Deflnilien  6.1.1  Data  flow  diagram 

A DFD  d is  0 i-(npfe  (T,  P,  S,  F,  R/  T is  o act  of  (erminels.  P is  o set  ofpracuscs. 
S M a set  of  data  stores.  F ia  a set  of  data  flow)  and  control  flows.  R is  a set  of 
relationships  among  data  flows  of  a process. 

There  are  two  dilfereot  types  of  terminals  in  a DFD-  One  is  a data  source  and 
the  other  one  is  a data  sink.  The  data  sources  generate  data  A sensor  ia  an  example 
of  the  data  sources.  The  data  sinks  receive  data  and  consume  them.  A printer  is  an 
example  of  the  data  sinks. 

The  data  store  in  the  DFD  is  a static  storage.  It  is  an  abstraction  on  a fi>.  A 
special  type  of  data  store  is  a buffer  in  which  the  flows  produced  by  one  or  more 
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processes  sre  subject  to  & storage  delay  before  being  consumed  by  one  or  more  traas* 
formations  [53j.  The  buffer  is  also  used  as  an  intermediate  passive  component  to 
interface  two  active  processes. 

The  data  Bow  shows  the  Bow  of  data  either  between  processes,  between  a terminal 
and  a process,  or  between  a process  and  a data  store.  The  control  Bow  (or  event  Bow) 
is  used  to  represent  the  flow  of  control,  such  as  a signal,  activation,  or  deactivation 
of  each  process. 

There  can  be  two  different  types  of  processes  in  a DFD.  One  is  a data  process, 
and  another  one  is  a control  process.  The  data  process  transforms  incoming  data  and 
generates  outgoing  data.  It  is  the  same  as  the  bubble  used  in  general  DFDs,  such 
as  the  DFD  in  (18).  The  concepts  of  active  input  and  active  output  are  important 
for  understanding  a data  process.  These  concepts  are  major  factors  considered  in 
the  tcansformatieo  method  by  which  a DFD  is  transformed  into  module  and  object 
diagrams  based  on  our  computation  model.  A data  process  may  have  at  most  one 
active  input.  An  active  input  ertives  independently  of  any  action  of  the  tecriving 
process  and  can  be  transformed  by  the  receiving  process.  Tbe  single  active  input 
may  converge  from  multiple  sources;  depending  on  the  labeling,  this  may  represent 
either  alternate  sources  of  input  or  the  aggregation  of  components  to  form  a single 
input  (53j. 

The  control  process’s  job  is  to  coordinate  and  synchronize  the  activities  of  other 
processes.  It  generates  control  signals  to  activate  other  processes.  Originally,  it  is 
not  included  In  the  DFD  in  (181.  The  original  DFD  lades  power  to  represent  the 
conlroi  behavior  of  systems.  Ward(53l  introduced  control  flows  and  control  processes 
in  his  DFD  to  overcome  this  limitation.  In  this  dissertation,  this  control  information 
representation  is  induded  in  the  DFD, 


The  incomiDf  d»t»  flows  of  e procees  or  the  outgoing  date  flows  of  a process 
may  have  ooe  of  two  relationships,  i.e..  and  or  or.  When  a process  has  incoming 


When  a process  baa  incoming  data  flows  with  the  or  relationship,  the  process  receives 
data  from  one  of  the  daU  flows.  When  a process  has  outgmng  data  flowa  with  the 
and  relatioQSbip,  the  pros 


lime.  When  a process  has  outgoing  data  flowa  with  the  or  relationship,  the  process 
generates  one  of  the  data  at  a moment.  For  example,  a spell  checking  process  may 
generate  an  acceptable  word  to  the  next  process,  or  an  unacceptable  srord  to  the 
error  handling  process.  In  this  case,  the  spell  checking  process  has  two  outgoing  data 


flows  with  or  relationship. 

In  Figure  6.1,  graphical  notations  of  a DFD  art  shown.  The  terminals  are  rep- 
resentod  by  rectangles.  The  daU  process  is  represented  by  a circle  with  a solid  line, 
and  the  control  process  is  represented  by  a circle  with  a dotted  line.  A parallel  solid 
line  denotes  a data  store.  A parallel  dotted  line  represents  a buffer.  The  data  flow  is 
represented  by  a labelled  arrow  with  a solid  line,  and  the  control  flow  is  represented 
by  a labelled  arrow  with  a dotted  line.  The  relationahips  are  represented  by  Che 
labels,  and  aod  or.  The  flow  of  the  same  data  to  multiple  processes  is  represented  as 
in  Figure  6.2.  Both  left  side  and  right  side  of  graphical  notations  are  equivalent.  For 
the  sake  of  convenience,  the  left  side  of  graphical  notation  is  used.  The  DFD  in  this 
dissertation  is  much  more  general  than  that  in  |53).  In  Rgure  6.3,  Ward’s  special 
notations  of  data  flows  and  the  equivalent  notation  are  shnwn.  Multiple  outgoing 
data  flows  with  or  relefimuhip  canoot  be  represented  by  using  tbe  Ward's  notation. 
Therefore,  tbe  DFD  has  much  mote  expressing  capabilities  aod  no  ambiguity. 


Tumicjl 

(Ml  source' Diu  sin 


Dau  Store 


rigure  6.1.  Graphic*] 


DeUFIowDiagra 
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Figure  fi.2.  Graphical  notalioD  of  a data  Row  to  multiple  deatinatioDi 

Data  flow  diagranu  can  become  quite  large  and  complex  for  large  software  »ye- 
temi.  Data  dictionaries  are  used  to  manage  complex  data  flow  diagrams  in  the 
requirement  analyeie  of  eoftware  development.  A data  dictionary  ie  an  orgaoiaed  list- 
ing in  which  information  about  ail  data  elements  are  stored.  It  describee  the  meaning 
of  data  items  shown  in  a data  flow  diagram,  euch  as  the  data  flows  and  data  stores. 
Each  element  in  the  data  dictionary  Is  precisely  and  rigorously  defined  so  that  both 
users  and  systems  aoalysist  will  have  a common  understanding  of  all  inputs,  outputs, 
components  of  stores,  and  inlermediale  calculations  [«].  Generally,  it  includes  the 
following  information  [16j: 

• name  of  the  data  item; 

• description/purpose; 


related  data  items; 
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Ward’j  DFD  uid  our  DFD 


tangc  of  values; 


s data  flows; 

s data  structure  deflojlion/form. 

Aliases  are  used  for  other  names  by  which  the  data  item  is  called.  Descrip- 
tioo/purpose  is  a textual  and  informal  description  of  what  the  data  item  is  used  for 
or  why  it  exists.  Related  data  items  are  used  to  represent  the  relationship  between 
data  items.  Data  flows  show  the  sources  and  the  destinations  of  data  items.  Data 
structure  definition /form  captures  the  composition  of  the  data  item  in  terms  of  other 
data  items. 

/Irfinilicn  6.1.1  Data  iiclionary 
A data  diclienery  DD  is  e set  of  data  definitions. 

DD  = DN  X DF  X DC  n BX, 

where  DN  is  a set  of  nemes  of  data  items,  DF  is  a set  of  data  fiotos,  DC  is  e set  of 
dueriptions,  and  BX  is  e set  of  eaprtsseons  to  represent  the  composition  of  each  data 


A typical  element  d in  a DO  consists  of  its  name,  its  source  and  destination  {i.e., 
data  flow),  textual  description,  and  its  composition  expression.  The  expression  for 
the  composition  of  each  data  item  is  represented  in  a Backus-Naur  Form  (BNF)  style 


I^ble  6.1.  Symbolt  for  dal&  rcprcKnUtion 


Meta  hvmbols 

Meaning 

+ 

T) 

ootional 

■n 

iteration 

1 1 

one  alternative  selection 

= 

is  comoosed  of 

0 

identifier  <kev  held)  for  a store 

expression  3 name  | “("expression”)'  | “("expression*}"  | 

•(”  expression  { “I"  expression}*  “)"  | expression  “+'  expression 

Several  simple  symbols  are  used  in  order  to  describe  (he  composition  of  the  data 
item.  Id  the  above  equation,  simple  symbols  are  enclosed  by  double  quotes  (“  "). 
Each  simple  symbol  and  its  corresponding  meaning  is  shown  in  Table  6.1.2. 

Data  dictionaries  are  also  used  in  completeness  and  consistency  checking.  The 
data  dictionary  is  one  of  the  primary  input  information  in  the  ADS  software  design 
method.  Its  information  is  directly  corresponded  to  the  compositional  information 
of  each  object  identified  in  the  design  phase. 

A state  transition  diagram  (STD)  represents  a process  specification  for  a control 
process  in  aDPD.  A STD  is  based  on  the  concept  of  a finite  state  machine.  The  finite 
state  machine  is  a hypothetical  machine  that  can  be  in  only  one  of  the  given  number 
of  states  at  any  specific  moment.  The  machine  responds  to  an  input  by  generating 


u output  and  cbaogiog  its  at&t«.  Both  the  output  &nd  the  next  state  ue  purely 
functions  of  the  current  state  and  the  input.  The  hypothetical  machine  for  STDs  in 
this  dissertation  is  a Mealy  model  [36]  of  a Suite  state  machine.  The  terminologies 
eonitition  and  aclioe  are  used  instead  of  the  input  and  the  output. 

р. fnilioa  6.I.!  Stale  transilian  diagram 

sfaie  tranaitian  diagram  a is  a S~lvplt  (Q,T,got  Q ^ u ^nife  atl  of  stoles. 

T is  a sel  of  transitions,  go  is  the  initial  state.  Qy  is  a set  of  final  stales.  L is  a set 
of  labels. 

OrdBition  6.1.1  TVansition 
A set  of  transitions  T is  defined  as 
T e QxQxL, 

vhert  Q is  a finite  set  of  states  and  L is  a set  of  labels. 
neSnitioa  S.I.S  Label 

A set  of  label  L in  a STD  consists  of  a iduple  (C,AJ,  where  C is  a sel  of  conditions 
of  a system  and  A is  a eel  of  actions  of  a system.  The  set  C can  include  element 

с,  that  denotes  a default  condition  in  the  stats  of  a system.  The  action  set  A can 
contain  element  Ot  that  denotes  an  empty  action. 

A condition  is  some  event  in  the  external  environment  that  the  system  is  capable 
of  detecting.  It  will  typically  be  a signal,  an  interrupt,  or  arrival  of  a packet  of  data 
So,  the  condition  in  the  STD  corresponds  to  the  incoming  control  0ow  of  the  DFD. 
Actions  in  the  STD  are  either  responses  sect  back  to  the  external  environment  or 
they  are  calculalioos  whose  results  are  recorded  by  the  system.  The  action  in  the 
STD  corresponds  to  the  outgoing  control  Sow  of  the  DFD. 


Pf^fiilien  S.I.S  A £<-(ro«ilii>n  r is  lit^nerf  os 
icAerf  r € r,  € Qt  ond  o*  € A 

Tbe  s.-WMisition  {c,,at))  ( € T)  implies  th»t  the  sUU  9,  is  changed  to 

the  state  unconditionally.  This  et-transillon  is  used  in  describing  tbe  internal 
sequential  operations  of  a process  in  a DFD. 
p.dnilinn  i?.l.7  A e.-(roiisi7ioa  r is  denned  os 
r = (9.-,?j.  (cs.a,», 
uftere  T 6 T,  9,,  € Q,  and  Cj  € C 

Tbe  c.-transilion  (91, 9,,  (esi  e<))  (E  7)  implies  that  the  stale  9,  is  changed  to  tbe 
state  9j  without  generating  output  to  the  external  environment. 
prliiiiiipn  S.I.S  A e'tmnsitioe  r is  defined  as 
c = (9., 9f.  {«..«<)). 
uAere  t € T,  9i,9j  € 0- 

Tbe  C'transition  {9i*«9j«{^ie()}  (€  T)  implies  that  tbe  state  9,  is  changed  to  tbe 

The  graphical  symbols  for  state  transition  diagrams  arc  shown  in  Figure  6.4. 
Each  state  is  represented  by  a rectangle.  Each  transition  between  two  states  is 
denoted  by  an  arrow  with  a corresponding  label.  Tbe  direction  of  tbe  arrow  shows 
the  sequence  of  tbe  state  change.  Each  label  consists  of  two  components,  condition 
and  action,  which  are  separated  by  the  bar.  The  transitions  ec*transition  and  tg- 
Iransition  are  represented  by  making  tbe  corresponding  parts  empty.  In  Figure  6.5, 
a state  transition  diagram  for  a simplified  vending  machine  is  shown.  State  idle  in 
this  diagram  is  tbe  initial  state  as  well  as  tbe  final  state. 
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TRANSmON 


LABEL 


CONDmON 

ACTION 


Figure  6.4.  Graphical  lymbola  for  STDs 


6.2  Outpul  of  Deeien  Phaae 

uied  . The  object  communication  diagram  and  the  clans  hierarchy  diagram  for  each 
module  are  used  for  tbe  graphical  roprescntation.  The  textual  represeotatioa  b done 
by  using  the  design  description  language. 


:alion  diaffmm  OCD  is  ilefined  ns 


DeUmtion  S.S.I  Obje 


r 
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Display  "kIcci  an  iter 


Waiting  for  choice 


Display  "wail" 


Figure  6.S.  A STD 


OCD  = {OBJ.  INV), 


iffhen  OBJ  a a set  oj  object  and  INV  u a act  of  object  method  invoca(i0n«. 

The  typical  element  of  OBJ,  obj  conaisls  of  ite  name  and  a Kt  of  ite  method 

namee,  i.e.,  ob]  = (obj'name,  metbodl,  method2 ).  The  Bet  of  object  method 

iDVocationB  INV  haa  a foUowiog  relationship. 

INV  C INV,  + INK, 

where  INV,  is  a set  of  local  object  method  invocation  and  INVr  is  a set  of  remote 
object  method  iovocation. 

The  set  of  local  object  method  iovocations  INV,  baa  a following  relatioosbip. 

INV,  Q ({e-j)  + OBJ)  X OBJ 

Tbe  notatioo  denotes  a dummy  object  that  does  not  exist  in  the  module.  The 
local  object  methods  can  be  invoked  by  the  other  local  object  or  by  tbe  body  of  the 
module.  To  represent  the  method  iovocation  by  the  body  rf  the  module,  the  dummy 
object  notation  Cat;  is  used  in  this  dissertation.  The  set  of  remote  object  method 
iovocations  INV,  has  the  foUowiog  relationship. 

INV.  C ((Cat,)  + OBJ)  X ({£.,;)  + OBJ)  - OBJ  x OBJ 
The  dummy  object  concept  is  also  used  in  representing  the  remote  object  method 
invocation.  Because  a remote  object  method  invocation  occurs  by  the  interaclion 
between  the  module,  the  rapreseoUtion  of  the  remote  object  method  invocation  in 
a module  is  represented  as  an  arrow  whose  tail  or  bead  is  not  connected  with  any 


Figure  6.6.  Object  commuQicatioo  diagrem 


component  in  the  diegram.  The  remote  object  method  iovocation  is  represented  by 
using  an  arrow  with  a dashed  line  to  distinguish  it  from  Ibe  local  object  method 
invocation  that  is  represented  by  using  an  arrow  with  a solid  line. 

Figure  6.6  shosrs  the  example  of  the  object  communication  diagram.  The  iovoca- 
tioD  of  the  remote  object  method  xiput  is  represented  by  an  arrow  with  a label  pul. 
The  object  method  delete  is  invoked  by  the  body  of  the  module.  The  method  ^ndof 
the  object  y is  iovoked  by  the  object  x. 


6.2.2  Class  Hierarcbv  Diasram 

The  class  hierarchy  diagram  represents  the  superclass  and  subclass  relationships. 


It  iaaset  of  directed  graphs.  E 


. hierarchy  relation  from  a superclass  to  a subclass. 


p>fimlion  S.t.S  Clatt  hienrehs  diagram 
A dass  hierardiy  diaffram  CHD  u defintd  w 

CHD  = (C,  H£), 

a/Kcrc  C it  a let  of  daites  and  HE  is  a set  of  kieranky  edges. 

A typical  element  of  HE,  ft  u a directed  edge,  i.e.,  ft  — (cl,<2).  Clast  cl  is  the 
superclass  of  class  eS. 

A typical  dement  c of  C in  the  CHD  consiaU  of  iU  atme  c and  a set  of  accessible 
method  M,  i.Ci  c — (c,  M)i  where  c = the  name  of  class  c and  M = + M,.  The 

class  c has  kfe,  the  set  of  its  own  methods,  and  the  set  tnetbods  inherited  from 
superclass  s. 

Id  Fi^re  6,7,  an  example  of  the  class  hierarchy  dia^ams  are  shown.  Class  C 
Is  the  superclass  of  class  B and  class  C.  Class  B has  the  method  rnetftod-e  that  is 
inherited  from  class  A.  Class  B has  its  own  method  metftod'U. 

6.2.3  Desitn  Deseriplion  Laneuase 

Our  design  description  language  (DDL)  is  for  establishing  a design  representation 
of  software  for  ADSs.  It  is  based  on  the  computation  modd  presented  in  this  disser* 
talion.  Therefore,  it  is  object  oriented.  Because  the  representation  is  abstract  and 
high-level  in  the  design  phase,  certain  details  about  the  program  are  not  specified. 
The  information  included  in  a design  phase  and  the  details  excluded  depends  on  the 
designer.  The  DDL  plays  the  role  of  a bridge  to  link  the  gap  between  the  output  of 
the  reijuitemenl  analysis  and  the  detailed  implementation.  Systematic  refinement  of 
software  design  and  coding  is  possible  by  using  the  DDL. 

The  following  properties  are  represented  by  using  the  DDL; 

• overall  structure  of  ADS  application  software  (a  set  of  modules); 


Figure  6.7.  Class  biersrch}'  diagram 


a iaUrfacea  of  each  module; 
a classes  for  local  objects  of  each  module; 

- abstract  representation  of  each  local  data. 


- high-level  description  of  behavior  of  each  method 


a behavior  the  body  of  each  module. 
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The  overall  atnicture  of  the  ADS  oppUcotion  aoftw&re  ia  repreoented  os  a set  of 
modules.  Each  module  is  described  by  usin|  the  DDL  constructs.  Each  module’s  def- 
inition consists  of  its  name,  interfaces,  cioss  derinitions,  and  its  body.  Each  module’s 
name  is  unique,  and  it  gives  abstract  meaning  about  its  internal  properties. 

The  interfaces  of  each  module  ore  described  by  the  dehnitions  of  import  object 
methods  and  export  object  methods.  Parameters  for  these  methods  are  also  defined. 
In  the  interface  dehnition,  the  types  of  interactions  among  modules  ore  implicitly 
defined.  There  ore  two  different  types  in  the  interface  definition.  One  ie  the  one-way 
type  {or  data-flow  type)  and  another  is  the  two-way  type  (or  client/server  type).  If 
the  remote  object  method  does  not  require  any  output  parameter  nor  the  result  of 
the  method  invocation,  then  it  is  on  one-way  type  object  method.  This  is  the  cose 
that  a sender  simply  sends  data  to  a receiver  and  does  not  need  any  response  from 
the  receiver.  If  the  remote  object  method  requires  some  output  parameters,  then 
it  is  a two-way  type  object  method.  To  distinguish  the  type  of  each  parameter  in 
the  remote  object  method  definition  keywords  In:  and  out:  ore  used  in  the  DDL.  If 
the  source  module  needs  to  know  whether  the  remote  object  method  is  invoked  and 
successfully  executed  or  not,  a two-way  type  remote  object  method  is  defined  as  on 
interface.  In  this  cose,  to  distinguish  the  two-way  type  remote  object  method  with 
no  output  parameter  from  the  one-way  type  remote  object  method,  a dummy  output 
parameter  is  used  with  key  word  out:. 

The  class  of  each  local  object  is  defined  with  its  name,  methods,  super-class, 
and  abstract  representation  of  its  compositions  (local  data).  The  definition  of  each 
method  of  the  local  object  consists  of  its  name,  guard  statement  (optional),  poat- 
condition  (optional),  and  behavior  or  functional  description.  The  guard  statement  is 
the  boolean  expression  as  already  mentioned  in  the  Chapter  4.  The  postcondition  is 
used  to  represent  the  state  change  of  the  object  after  the  object  method  execution.  It 


more  concrete  Mm&nlic  design  information  to  a programmer.  By  giving  post, 
condition  information,  the  designer  can  ensure  that  the  programmer  wiii  write  the 
correct  program  [37].  The  new  states  of  each  object's  components  are  represented 
by  adding  the  prime  symbol  (/]  to  the  original  name.  For  example,  the  statement 
in  a postcondition,  length’  = length  + 1,  denotes  that  the  value  of  the  composition 
iengtb  is  increased  by  1 after  the  execution  of  the  object  method. 

The  compositions  are  represented  by  using  the  following  type  constructs:  integer, 
real,  char,  string,  array,  list,  and  set.  We  have  booiean  and  logical  operators 
in  the  DDL,  such  as  and,  or,  not,  '==*,  and  ■!=',  The  behavior  of  each 
method  is  represented  by  using  the  operation  constructs:  if  then  else,  case, 
while()  do,  and  return.  The  semicolon  construct  (;]  is  used  to  represent  the 
sequence  of  operation.  The  dash  conslrucl  (-)  is  used  for  the  designer  directive.  The 
syntax  of  the  DDL  is  defined  with  extended  BNF  notalioo  in  the  Appendix  of  this 
dissertation.  The  example  of  the  DDL  usage  is  shown  in  the  Section  6.2. 


TRANSFORMATION  OF  THE  DATA  FLOW  DIAGRAM 


The  tr&xiaformation  method  serves  to  link  the  semantic  gap  between  the  data- 
Sow  model  based  requirement  analysis  and  the  object-oriented  design.  By  using 
this  method,  the  module  interfaces  are  established.  Each  remote  object  method  is 
defined  based  on  the  activation  relation  and  the  direction  of  a data  flow  between 
two  modules.  To  maximise  the  utilisation  of  ADS  environments  and  to  increase  the 
on-line  capability,  the  one-way  type  of  method  invocation  is  primarily  used. 

T,1  Classificatione  of  Components  in  Data  Flow  Diaerams 
Following  are  the  components  of  the  data  flow  diagram  classified  into  three  dif- 
ferent groups  baaed  on  their  activation  properties: 
a active  components; 
s passive  components; 
a pseudo  active  components. 

In  the  data  flow  diagram,  each  control  process  activates  data  processes  linked  to 
it.  Some  data  sources  or  data  sinks  can  also  activate  data  processes.  They  are  called 
nctioe  Irrminols  in  this  dissertation.  The  control  processes  and  active  terminals  are 
classified  as  scfiue  componenfa  in  the  data  flow  diagram  in  this  dissertation.  Each 
active  component  in  the  data  flow  diagrams  can  process  its  operation  asynchronously 
with  regards  to  the  other  active  components.  It  may  have  its  own  control  threads. 
The  data  stores  or  buffers  do  not  activate  other  processes.  The  passive  data  sources 
or  data  smb  also  do  not  activate  any  other  processes,  but  are  activated  by  other 
components.  Such  components  are  called  possice  componcfits.  The  data  process  can 
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activate  other  data  processes,  and  it  can  be  activated  by  the  active  component  or 
another  data  process.  They  are  classified  as  pseudo  defies  components. 

Delinilion  7.1.1  Relativelp  active  (passive)  components 

If  the  component  A activates  the  component  B that  is  tinted  to  A in  the  data  flow 
diaffcam,  A (S)  is  called  a relatively  active  (passive)  component  against  B ^A^. 

Active  components  in  the  data  flow  diagrams  are  relatively  active  components 
against  the  passive  or  paeudo  active  components.  The  pseudo  active  components  are 
active  components  against  the  passive  components.  The  control  process  is  a relatively 
active  component  against  the  data  process.  If  the  two  data  processes  A and  B are 
activated  by  different  active  components,  it  cannot  be  decided  what  the  relatively 
active  component  relationship  is  between  them. 

nehnition  l.I.S  £lguivalently  active  components: 

If  the  two  components  A and  B,  between  which  a data  flaw  u connected,  art  activated 
by  different  active  (or  relatively  active)  components,  then  A and  B art  defined  as 
eguioalentiy  active  components  against  each  other. 

The  equivalently  active  components  are  processed  asynchronously,  because  their 
relatively  active  components  work  asynchronously.  Figure  7.1  shows  an  example  of 
equivalently  active  components.  The  data  process  DPI  is  activated  by  the  control 
process  CPI,  and  the  data  process  DP2  is  activated  by  the  control  process  CP2  in 
this  case.  DPI  and  DP2  are  equivalently  active  components  against  each  other. 

The  data  flow  diagram  may  have  a cycle  of  data  flows.  If  a cycle  is  included  in 
the  data  flow  diagram  and  there  is  no  passive  component  in  that  cycle,  then  every 
data  process  in  that  cycle  is  an  equivalently  active  component.  If  there  is  at  least  one 
passive  component  in  the  cycle,  then  no  equivalently  active  component  can  exist. 
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Figure  7.1.  Ei^uivaJently  active  componeota 

We  will  oae  the  nolationa  >-  and  = to  repreaent  the  activation  relationahip  between 
the  componenta  of  the  data  flow  diagram.  The  expresaion,  x i y denotes  that  x ia 
a relatively  active  component  agunat  y.  The  expression,  x = y implies  that  x and  y 
are  equivalently  active  componeota  against  e»rh  other. 

Both  >-  and  = have  the  transitive  property.  If  x i (=  ) y and  y ► (4  ) j are 
true,  then  x >-  (=  ) z is  also  true.  The  relation  4 has  the  symmetric  property,  i.e.,  if 
X = y is  true  then  y 4 x is  also  true. 

Before  applying  the  transformation  method  to  a decompcoed  data  flow  diagram, 
the  data  flow  diagram  is  checked  as  to  whether  there  is  a data  flow  between  equiv- 
alently active  components  which  are  in  different  modules.  If  there  is  such  a data 
flow,  the  equivalently  active  relationship  between  two  components  U eliminated  by 


iDserting  the  passive  component  bulTer  between  the  components.  The  buffer  can  »• 
side  either  in  the  source  module  or  in  the  destination  module.  If  the  buffer  resides  in 
the  source  moduJe,  the  interface  of  two  modules  becomes  a client/server  type  remote 
object  method.  If  the  buffer  resides  in  the  destination  module,  the  iuterface  becomes 
a data  flow  type  remote  object  method. 

f>fffnirion  7,1. S Aetio^ion  path 

The  activation  path  A^te  ia  denned  by  Ap^tk  — (co,  C],Cs...,Cn},  uAsre  Q)  an  active 
component  and  cq  >-Ci  >-Ca  V...  V-Cp.  The  element  co  ie  called  ns  Acad  component 
and  Cn  is  called  as  tail  component. 

Usually,  the  last  element  c.  Is  a passive  component  in  an  activation  path.  A 
cycle  can  exist  in  a data  fiow  diagram.  If  the  cycle  is  connected  with  single  active 
components,  there  are  no  equivalently  active  components.  Por  example,  the  control 
process  cp  is  connected  with  the  data  process  dpi  and  dpi  is  a component  of  the 
cycle;  dpi  -•  dp2  -•  dp3  -•  dpi.  In  this  case,  an  activation  path  is  defined  as 
(cp,dpl,dp2,dp3).  So,  dpi  is  the  relatively  active  components  against  dp3  in  this 
case,  even  though  the  data  flow  direction  is  from  dp3  to  dpi.  Figure  7.2-b  shows 
the  activation  path  with  special  case — a cycle  in  a data  flow  diagram.  Figure  7.2-a 
shows  a general  ease.  There  are  two  activation  paths  in  the  case  (a),  i.e.,  (cp,  dpi, 
Dstore)aod  (cp,  dpi,  dp2,  dp3,  Dstore),  Dstorc  is  a passive  terminal  in  this  example. 
In  (b),  the  data  process  dpi  is  activated  by  the  control  process  cp  and  then  accepts 
the  datum  dfl  and  generates  the  datum  df2  or  df3  based  on  some  conditions. 

rACfrcrq  7-ltl  If  the  dfrsefion  of  the  activation  path  is  corresponded  to  the  direction 
of  the  data  flotc  hetaeen  (too  modules,  the  interface  of  those  modules  is  a data  fioa 
type  of  remote  object  method. 
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Figure  7.2. 


thai  then  are  two  compononU  A and  B,  addeh 


ineUdeJ  in  ^i^erent  modutee  Mo  and  Mi  nspeclivels.  A ioa  nlatioelg  active  compo- 
nent against  B-  A oa^  B are  the  source  and  the  destination  of  the  datum  s respectively^ 
If  the  ohjeet  method  for  the  two  modules' interaction  is  defined  la  the  module  Ma, 
then  module  Mb  should  invoke  the  method  to  inferaef  wilA  t^e  madu/e  Ma.  In  this 
case,  the  nlolivety  active  component  Ma  is  activated  by  the  retatively  passive  com- 
ponent Mi.  It  is  semantically  wrong.  So,  the  object  method  should  be  defined  in  the 
module  Mb.  If  the  object  method  is  defined  in  the  module  Mb,  then  the  met^o^  has 
the  input  parameter  s and  no  output  parameter.  Therefore,  the  object  method  is  a 
data  flow  type.  □ 

Theorem  7.I.S  If  the  iireclian  of  the  activation  path  does  net  correspond  to  the  di- 
rection of  the  data  flow  between  two  modules,  the  interface  of  these  modules  is  a 
dieni/server  type  of  remale  object  method. 

Proof  al  TTieorem  7. 1.!  Assume  that  there  art  two  components  A and  B,  which  are 
included  in  different  modules  Ma  and  Mb  respectioely.  B is  a relatively  active  compo- 
nent against  A.  A and  B are  the  source  and  the  destination  of  the  datum  i respectively. 
The  object  method  for  two  modules'  inleraetion  should  be  defined  in  the  module  Ma, 
freeauee  Ma  is  a relatively  passive  component  against  Mb.  In  this  ease,  the  melAa^ 
has  an  output  parameter  t la  send  the  result  to  Mb.  Mb  invokes  the  object  melAarl 
onif  receives  the  output  x.  So,  it  is  a clieal/eeruer  type  object  method.  □ 

De/inition  7.I.J  Biconnected  modules: 

If  the  module  A contains  both  head  and  tail  components  of  an  aeliualian  path  and 
the  module  B cenlaina  el  least  one  component  of  the  same  aelivaltoa  path,  then  the 
module  A and  B are  biconnected. 


Figure  7.3  sbowa  examples  of  the  bionneeted  modules  in  a decomposed  data  Sow 
diagram.  Two  modules  illustrated  in  (a)  are  connected  with  the  data  Sows  x and  s, 
uid  (b)  is  the  case  that  two  modules  are  connected  with  the  control  Sow  c and  the 
data  Sow  y. 


In  order  to  explain  the  transformation  rules  for  the  establisbmeot  of  module  in* 
terface,  the  following  Dotations  are  used: 

DP:  set  of  data  processes 

PPi',  set  of  data  processes  in  the  module  i 

CP:  set  of  control  processes 

CPi^  set  of  control  processes  io  the  module  i 

DS:  set  of  data  stores 

da:  oame  of  the  data  store  ds  (€  DS) 

DF:  set  of  data  Sows 
CF:  set  of  control  flows 

R:  set  of  relationship  between  outgoing  data  flows  or  incoming  data  flows  of  each 

XMi'.  set  of  the  export  object  methods  of  the  module  i 
/Af,:  set  of  the  import  object  methods  of  the  module  i 

Baaed  on  the  theorem  7.1.1  and  theorem  7.1.2,  the  following  transformation  rules 
are  made.  Each  rule  is  delined  case  by  case. 

Rule  1:  (data  process  to  data  process} 

DFD  condition;  (dp,  y dps)  A {{dp.,dp^,x)  6 DF)  A dp,  € DP  A dpi  € DP,  A i j!  j 


dpi  dp2  dp3  dpi 


qi  >■  dpi  >■  >■  dp3 


(b> 

Figure  7.3.  BIcoonected  modiileg 


Module  interface:  x!dpi(x:in}  € /M,  A xldR((x;in)  6 XM, 


If  tbe  boundary  of  two  modules  in  a decomposed  data  flow  diagram  intersect  a 
data  flow  between  two  data  processes  and  the  sender  is  a relatively  active  component 
against  tbe  receiver,  tbe  interface  of  the  modules  becomes  the  data  flow  type  remote 
object  method.  The  label  of  the  data  flow  becomes  the  input  parameter  and  the 
name  of  the  remote  object.  This  is  a similar  method  to  Alabiso’s.  In  this  case,  the 
data  flow  does  not  have  and  relationship  among  any  other  data  flows.  In  Figure  7.4, 
tbe  transformation  rule  is  represented  graphically. 

Rule  2 : data  process  to  data  store 

DFD  condition:  ((dp,,ds,x)  € DF  A dp.  € DPi  A ds  g DSj  A i ^ j 
Module  interface:  ds.put!(x:io)  g IM,  A ds. put!(x:in)  € XM/ 

Data  processes  are  relatively  active  components  against  data  stores.  So,  the  data 
flow  from  tbe  data  process  to  data  store  is  transformed  into  an  module  interface  with 
a data  flow  type  remote  object  method.  The  notation  da  denotes  the  name  of  the 
data  store.  The  label  of  data  flow  become  the  Input  parameter  of  tbe  object  method. 
Figure  7.5  shows  graphical  representation  for  this  case. 

Rule  3 : data  store  to  data  process 

DFD  coudition:  ((ds, dps, x)  € DF  A ds  € DJ.  A dps  6 DPj 

Module  interface:  ds.get'(x;out)  € XMi  A ds-gel!(x:out)  € IMj 

The  data  flow  from  tbe  data  store  to  the  data  proems  is  transformed  into  an 
module  iuCerface  with  a client/server  type  remote  object  method.  The  method  is 
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Figure  7^.  TriiMforniiition 


Rule  2: 


delink  ID  the  source  module,  and  it  has  an  output  parameter  that  is  equivalent  to 
the  label  ^ the  data  flow.  Figure  7.6  shows  the  graphical  representation  tor  this  case. 

Rule  4 : data  process  to  buffer 

DFD  condition:  ((dp,  ,bf,x)  € DF  A dp,  € DP,  A 6/  € BFj  A i ^ j 
Module  interface:  i7'Piit!(x:ia)  E IMi  A i/.put!(x:in)  € XMj 

fUile  5 : bufler  to  data  process 

DFD  condition:  ((bf,dps,x)  E DF  A 6/  g BFt  A dps  E DPj  j 
Module  interface:  6/.get!(x:out)  E JVAf,  A S7-get!(x:out)  € IM, 

Rule  4 and  rule  5 are  the  same  as  rule  2 and  rule  3 respectively.  However,  in  the 
detailed  design  phase,  the  method  pul  (or  get)  is  designed  differently  from  that  in  rule 
2 (or  rule  3).  Because  the  buffer  is  used  to  synchronise  the  two  different  modules’ 
interaction,  a flag  is  added  into  the  compositions  of  the  object  bf.  Figure  7.7  and 
Figure  7.8  show  graphical  representations  tor  rules  4 and  5 respectively. 

Rules  6 to  9 axe  related  to  the  data  flow  between  different  types  of  terminals  and 
the  data  process.  Rule  6 and  rule  8 are  similar  to  rule  1.  On  the  other  hand,  rule  7 
and  rule  9 are  similar  to  rule  3,  i.e.,  they  are  client/server  typa. 

Rule  6 : active  data  source  to  data  process 

DFD  condition;  (I,  >i  dp*)  A ((l„dp*,x)  E DF)  A (,  6 I)  A dp*  e DP,  A i j!  j 
Module  interface;  i!dp*(x:in)  € /«,  A i!dp*(x:io)  E XM, 
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Figure  7.6.  Trensfomiation  Rule  3:  date  store  to  data 
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FipiM  7.7.  T« 


«7 


<5Pd 


bf 


( 


Figure  T.8.  Trausfo 


Rule  5: 


R,ule  7 : passive  data  source  to  data  process 

DFD  condition:  (dp<  y t,)  A ((l„dps,«)  e DF)  A I.  6 T",  A dps  € DP,  A t j!  j 
Module  interface:  t^!dp^(x:out)  € XMi  A C'dps(x:out)  € IM, 

Rule  8 : data  process  to  passive  data  sink 

DFD  condition;  (dp,  y (<)  A ((dp„<s,x)  S DF)  A (dp,  6 DP.)  A («x  € 7))  A i jt  J 
Module  interface:  ts!pu((x:in)  € 7M,  A tslput(x;in)  € JfA/, 

Rule  9 ; data  process  to  active  data  sink 

DFD  condition:  (t<  i dp.)  A ({dp„fs,x)  £ DF)  A {dp,  € DP;)  A {UST,)  Ai^j 
Moduie  interface;  i!dp,(x;oul)  £ XM;  A i!dp,(xrout)  £ IM, 

A module  boundary  may  intersect  a control  flow  in  a decomposed  data  flow  di- 
agram, even  though  it  is  recommended  to  reduce  such  cases  in  the  ADS  software 
development.  The  destination  component  would  be  either  a data  process  or  a control 
process  in  this  case.  Rules  10  and  II  are  used  to  transform  the  control  flow  between 
the  modules. 

Rule  10  : control  process  to  data  pioces 

DFD  condition:  ((cp„  dps,  c)  £ CP)  A (cp,  £ CP.)  A (dp<  £ DPj) 

module  interface:  (vSeO  £ XM,)  A(tio!c()  £ IM;) 

The  control  flow  to  the  data  process  is  used  to  activate  or  deactivate  the  operation 
of  the  data  process.  Virtual  object  name  Co  is  used  here.  In  the  later  design  stage, 
the  actual  object  is  defined.  No  input  and  output  parameters  are  required  in  this 


type  of  the  object  method.  Figure  7.9  represents  thegrsphicel  notations  for  this  rule. 


Rule  1 1 : control  process  to  control  process 

DFD  condition:  ((cp,,c7a,e)  € CF)  A (cp„q><  6 CPi) 

module  interface:  (/(j!e()  6 XM,)  A(/lp!c()  e /Af.) 

The  control  flow  between  control  processes  represents  the  signal  or  event  that 
causes  to  change  the  state  of  the  system.  A special  object  Jig  is  used  to  represent 
the  state  change  information.  Figure  T.IO  shows  the  graphical  representation  of  this 
transformation. 

Rule  13  ; same  data  to  multiple  destinations 

DFD  condition:  ((s,d;,i).  (s,d.,a)  € DF)  A(s  € DP:  U71)  A (dy  6 DP,  U 7j)  A 
(d.  6 DP.UT.)  A(((s,d„*),(s,dj,a),af>d)  e R)  A(s  id,)  A 
(a  f.d,)M,i},ik 

Module  interface;  i!tim(x:in)  € IMi  A i!0m(x:in)  6 XM,fi  i!Cm(x:ia)  € XMt 

Rule  13  is  used  to  utilise  the  hroadcasting  capability  of  the  ADS.  The  source 
component  s it  a relatively  active  component  against  aU  iU  destination  components, 
and  the  outgoing  data  flows  have  an  and  relationship.  The  same  data  ate  generated 
by  the  source  module  and  sent  to  the  multiple  destination  modules  at  the  same  time. 
In  this  case,  each  destination  module  may  use  a dilfercnt  object  method-  A virtual 
object  method  is  used  in  the  module  interface  definitions  for  this  case.  Only  the 
virtual  object  method  i!5m(x;in)  is  known  from  the  viewpoint  of  the  outside  of  each 
module-  The  actual  object  method  corresponding  to  the  virtual  object  method  is 
defined  in  each  module.  Each  module’s  functionality  is  bidden  from  other  modules. 


cp. 


<>?i 


I 


Module-i 

■■olcO 


Figure  7.9.  TVenrfonnation  Rule  10:  control  process  to  data  pr 
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Figure  7-10.  IVaiuformdtion  Rule  11:  control  process  to  coutrol  procra 
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Figure  7.1 1.  TysjMfonn&tioo  Rule  12  : same  date  to 


U ia  & kind  of  information  biding  mochaniam.  Figure  7.11  shows  Ibe  graphical  repre< 
sentation  for  this  rule. 


Rule  13  : multiple  data  to  multiple  destinationa 

DFD  condition:  ((a,dj,*),(a,dt,y)  € DF)  A(a  € DflU7'i)A(dy  g DP,VT,)/\ 
(da  € Z>F,  ur.)  A(((a,d„sr),(s,da,y).ond)  e R)  A(a  4d,)  A 
(a  ids)  Ai  j!  j ?!  i 

Module  interface;  lltim(x«y;in)  g IMi  A ilvm(x,ynn)  € XMj 
A i!imi(*,y;in)  € XMt 


Rule  13  is  the  aame  aa  Rule  12  except  that  the  data  for  each  destination  module 
are  not  the  aame.  In  Ibis  case,  avirtual  object  method  iaused  too.  The  virtual  object 

data.  In  the  actual  object  method  deRuition,  only  required  parameten  are  deRned, 
i.e.,  unnecessary  parameters  are  not  dcRncd.  The  set  of  an  actual  object  method’s 
input  parameters  are  the  subset  of  the  virtual  object  method’s  input  parameters. 
Figure  7.12  shows  this  transformation  rule. 


Rule  14  : same  cvent/signal  to  multiple  destinations 

DFD  condition:  ((ea,dr,c),(cs.d,.c)  € CF)  A(es  6 CF.  U 71)  A 

(dj  € DPj  (J  CPj  U r,)  A (ds  6 DPk  U cn  U Ts)  A 

(((e».<<ri«),(c5,dj,e),snd)  e R)  Ai  # J ^ i 
Module  interface;  55S!c()  6 /M,  A i«a!e()  g Jf  Af^A  um!c()  g XM^ 

Rule  14  Is  similar  to  Rule  12  except  the  control  signal/event  instead  of  the  data 
is  considered  in  this  case.  So,  it  is  the  control  flow  ver«on  of  Rule  12.  However. 
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Figure  7.12.  IVensfonnetiOD  Rule  13  : multiple  del*  Ut  multiple  destinslions 


the  control  flow  version  of  Rule  13  is  not  needed,  because  the  different  signals 


events  are  asynchronously  generated  from  the 


rigure  7.13  is 


Rule  15  and  Rule  16  are  applied  for  the  transformation  of  the  bicoonected  mod* 
ules.  In  transforming  the  case  of  the  bicoonected  modules,  the  interface  is  established 
by  using  the  cUeot/scrver  type  of  object  method  or  the  data  flow  type  of  object 
method,  i.e.,  there  are  two  choices.  The  client/server  type  has  some  advantages,  such 
as  simplification  of  the  interface  structure  and  understandability.  On  the  other  band, 
the  data  flow  type  also  has  some  advantages,  such  as  flexibility  and  expandability. 

Rule  15  : biconoected  modules  (with  data  flows) 

DFD  condition:  ((dp.i.dpn.x),  (dpA,<fp^,y)  € DF)  A {ip,i,dp,a  € DP,) 

A (dpoidpej  6 DPj)  A ( dp,i  >-dp,j  >-dpn  >-<fp.j) 

Module  interface:  i!dpn(j  : in.ji : out)  e /Af,  Ai’ipj,{z:  in,y  : out)  € XMj 

This  rule  is  applied  in  case  both  outgoing  and  incoming  connections  between  two 
modules  are  all  data  flows.  In  this  case,  the  object  method  has  both  input  aod  output 
parameters.  The  outgoing  datum  becomes  an  input  parameter  of  the  object  method, 
and  the  incoming  connections  becomes  an  output  parameter.  Figure  7.14  shows  the 
graphical  representation  of  this  rule. 

Rule  16  : bicoonected  modules  (with  control  flow  and  data  Bow) 

DFD  condition:  ((cp.i, dpn)  6 CF)  A (dpsj.dp.j.y)  € DP)  A (cp.,  iCP,)A 

(dpii  6 DPi)  A (dpji.rfpaj  6 DPj)  A ( dp,i  >-dpa  >-dp«  ►dp,j) 
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Figure  7.13.  TVuueforznatioa  Rule  H; 


veut/siguul  to  multiple  desllDutions 
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Figure  7.14.  ’lYaosfcrmation  Rule  15:  Biconnceled  module* 


Module  interface;  : out)  £ f Mi  A y\dp4i{y : out}  € XMj 


This  rule  is  applied  in  case  the  control  flow  and  the  data  flow  are  connected  with 
opposite  dicectiODs  between  two  modules.  In  this  case,  the  object  method  does  not 
have  ao  input  parameter.  The  incomin|  datum  becomes  an  output  parameter  with 
the  same  way  in  Rule  15. 

The  transformation  rule  for  the  outgoing  data  flows  vritb  or  relationship  is  not 
defloed  here.  However,  each  data  flow  of  this  case  is  transformed  separately  because 
or  relationship  denotes  each  data  flow  is  activated  at  the  different  condition.  So,  in 
a transformation  stage,  the  or  relationship  is  neglected. 

Lemma  7.g.I  Each  traniformalion  rule  preserues  the  meaning  of  the  input  model. 

Proof  of  Lemma  7.S.I  fn  the  datafiow  model,  a refativefy  sctiue  eornponent  activotes 
the  operation  of  the  rtlalivelp  pnssiue  rompsnenls  vhkh  are  direetly  connected  to  the 
relatively  active  component.  The  operations  of  the  components  in  the  same  eclipalion 
path  ore  seyuentinf  and  the  operations  of  the  components  in  the  different  activation 
path  are  concurrent. 

Rules  i,  S,  I,  $,  and  8 are  related  to  a data  floio  from  a relatively  active  eompo- 
nenl  to  a relatively  passive  component.  The  relative  active  component  activates  the 
operalioa  of  the  re/oticelji  pnjsiue  component  by  sending  data  in  these  eases.  The  data 
flow  type  of  object  method  preserves  the  onjinal  meaninj  of  these  types  of  data  flow. 

/tales  S,  S,  7,  and  9 are  related  to  data  flow  from  a relatively  passive  component 
to  a relatively  active  component.  The  relatively  active  component  aelivates  the  dale- 
sending  operation  of  the  relatively  passive  component.  The  client/server  type  object 


method,  with  output  parometeru  and  no  inpat  parameter,  prtoorou  the  onpinst  moan* 
inp  0/  these  tppes  of  dataflow,  i.e.,  it  prejerDoa  the  onpinat  direation  of  the  data  flow 
and  the  control  flow. 

In  the  ease  of  Rule  10,  a control  process  actinatoa  a data  process  by  sending  the 
control  in/ormation.  It  does  not  require  any  response  from  the  data  process  in  tAu 
ease,  i.e.,  fAe  flow  is  unidirectional  The  data  flow  type  of  object  method,  with  no 
parameter,  preserves  original  meaning  of  the  diagram. 

In  the  case  of  Rule  II,  a control  process  sends  its  control  information  to  another 
control  process.  The  delivery  of  the  contfot  information  to  a controt  process  means 
there  is  a state  change  or  an  event  occurs  in  the  system.  So,  the  data  flow  type  of  an 
object  method,  with  no  parameter,  preserves  the  cnpinot  moaninp  of  this  ease. 

Rule  IS,  Rule  IS,  and  Rule  If  are  rotated  to  the  case  that  a relatively  active 
component  sends  the  data  or  control  information  to  multiple  relatively  active  com- 
ponents eoneurrenlly.  The  data  flow  type  of  object  method,  vdiich  does  not  have  an 
output  parameter,  preserves  the  original  itireetion  of  the  data  flow  or  control  flow. 
The  broodcasling  eapaiililp  of  the  object  method  preserves  the  concurrent  activation 
of  the  multiple  components'  operations. 

In  the  eases  of  Rule  IS  and  Rule  IS,  lioo  moitvtea  are  bieonneeled  with  an  acti- 
vation path.  In  these  eases,  data  or  eontrot  information  is  sent  to  the  client  module, 
and  the  operations  of  the  components  in  lAe  client  mo^ute  art  oepuentiattp  performed. 

server  module.  The  client/server  type  of  object  method,  that  has  at  least  one  output 
parameter,  preserves  the  original  itireelian  of  the  data  flow  and  the  cantrot  ^su.O 

Lemma  T.S.t  All  cases  of  data  flow  diagrams  can  be  transformed  by  using  the  trano* 
formation  rules. 
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' rTuiDfl/enlljr  active  component  in  the  Iroiu- 


formation  otage,  the  cooeo  of  n>/«  I to  If  are  all  posoiile  eemiinationi  for  ovtgoing 
Jala  fiorot  anJ  eonlnj/  data  flova.  The  cases  of  rvte  IS  and  rule  IS  are  redundant 
to  the  earlier  cases.  The  incoming  data  floas  vnlh  or  (or  and)  relationships  are 
separately  transformed.  Therefore,  all  cases  of  data  flout  diagram  can  he  transformed 
by  using  the  combinations  of  the  transformation  rules.  D 


Dehnition  7.8.1  completeness: 

A transformalian  is  called  complete  if  its  oulpul  does  not  lose  any  of  the  originally 
given  semantic  meaning  of  lia  inysl. 

Theorem  7,j./  The  Iransfarmalian  based  on  above  rules  is  complete. 

Proof  of  nttrem  7£J  By  the  lemma  T.g.S,  all  eases  in  the  data  flout  diagram  can  be 
of  the  rlfllo^ow  diagram  that  is  the  input  model  of  our  Iransformotion  melhod.O 


ADS  APPLICATION  SOFTWARE  DESIGN 


FVom  Ihe  requirement  injJysis  ph»se,  the  d»l»  flow  diagram,  d»t»  dictionary,  and 
itate  transition  diagram  of  the  system  are  generated.  In  the  decomposition  stage, 
the  data  flow  diagram  is  decomposed  into  a set  of  correiated  components,  and  the 
module  boundaries  are  decided. 

After  the  decomposition,  each  distributed  moduie  is  designed  based  on  the  object- 
oriented  method-  The  transformation  method  is  used  to  transform  the  decomposed 
data  flow  diagram  into  the  modules  and  objecU  which  are  based  on  our  computation 

The  following  steps  are  performed  after  the  decomposition; 

I)  establish  module  interfaces; 

S)  identify  objects  and  classes  of  each  module; 

3}  establiah  the  claas  interface; 

4)  identify  the  relationships  among  objects; 


S)  design  the  composition  and  methods  for  each  object; 

7)  determine  the  body  of  module. 

Steps  1 to  4 are  considered  as  the  high-level  design  stage.  The  detailed  design 
information  is  decided  after  step  4.  The  first  step  i.  processed  with  the  transformation 
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melhod.  This  transformalion  method  ia  explained  acparalely  in  Chapter  7.  Before 
applying  the  tranafocmatioc  method,  equivalently  active  componeota  are  removed. 

la  atep  2),  identification  cd  objecti  and  claaaea  ia  done  by  uaing  the  data  flow 
diagram  and  the  data  dictionary  from  the  requirement  analyaia  phaee.  All  phyaical 
entitiea  which  correapond  to  real-world  objecta,  aueb  aa  aenaora  and  control  devices, 
and  logical  entities  are  identified  as  objecta.  The  data  flows  (or  data  in  tbe  data 
dictionary),  data  atores,  bufTcra,  and  terminals  are  objecta  in  tbe  design  phase. 

In  step  3),  class  interfaces  are  determined  by  identifying  methods  provided  by 
garb  object  class  and  then  by  defining  the  inputs  and  outputs  of  those  methods. 
The  identification  of  methods  is  done  by  using  tbe  data  flow  diagram.  Based  on  the 
transformation  method  [3,  SI],  tbe  name  of  a data  process  becomes  that  of  a method, 
and  the  incoming/outgoing  data  flows  to  the  data  process  become  iaput/output  pa. 
rameters  of  a method.  Tbe  name  of  an  actual  object  method  that  corresponds  to  tbe 
virtual  object  method  and  its  parameters  are  decided  in  this  step. 

In  step  4),  the  static  relationships  among  objecta  are  specified  by  uaing  the  object 
communication  diagrams.  The  invocation  directions  are  represented.  Tbe  remote 
object  method  invocations  and  the  local  object  melhod  invocations  are  represented 
by  using  tbe  different  notations. 

In  step  S),  the  commonality  between  different  claaaes  are  identified.  A set  of  oper- 
ations and/or  attributes  that  are  common  to  more  than  one  class  can  be  abstracted 
into  tbe  so  called  rupercloaa.  Another  way  to  make  tbe  class  hierarchy  ia  to  use  the 
information  about  the  structure  of  compound  attributes.  A complex  attribute  con- 
aiata  of  a set  of  more  simple  attribulea.  The  complex  attribule’s  operations  wiU  be 
inherited  from  tbe  several  simple  attributes'  operations.  The  establishment  of  class 
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hierwcliy  increues  the  reusability  i>f  application  software.  It  also  increases  the  mod- 
ularity and  the  extensibility  of  the  software  [44].  The  class  hierarchy  is  represented 
by  using  the  class  hierarchy  diagram  established  in  this  step. 

In  step  6),  (he  composition  and  the  methods  for  each  object  are  determined.  The 
composition  is  decided  based  on  the  data  dictionary  from  the  requirement  analysis 
phase.  Each  method  is  designed  more  precisely  based  on  (he  data  flow  diagram  and 
the  state  transition  diagram.  Synchronization  of  shared  object  access  is  described  in 
this  step  by  using  the  guard  statement.  The  post  condition  of  each  method  is  defined 
in  this  stage.  During  this  step,  the  designer  may  identify  some  new  objects  for  the 
detailed  design  of  each  method.  Those  objects  are  not  identified  in  the  previous 
steps,  because  they  are  not  specified  in  the  problem  domain  but  are  required  for  the 
detailed  design  stage.  So,  the  designer’s  experience  and  intuition  may  be  added  in 
this  step.  If  a new  object  is  identified,  then  the  previous  steps  are  repeated  for  that 
object.  Fault-tolerance  at  the  application  program  level  is  also  considered  in  this 
step.  Exception  handling  routines  for  a remote  object  method  invocation  is  designed 
to  support  fault  tolerance,  in  case  the  remote  object  method  invocation  is  a part  of 
the  method  description  for  a local  object. 

In  the  last  step,  the  body  of  each  module  is  designed  based  on  the  dynamic  be- 
havior of  the  system.  We  use  the  data  flow  diagram  and  the  state  transition  diagram 
generated  from  the  requirement  analysis  phase  to  determine  the  body  of  the  mod- 
ule. From  both  diagrams,  we  can  get  the  control  flow  information  for  each  module, 
such  as  the  sequences  of  object  method  invocation.  In  this  step,  fault  tolerance  is 
also  conudered  as  in  step  6).  Those  design  specifications  are  represented  by  the  de- 
sign description  language  which  is  based  on  the  compulatioo  model  presented  in  this 
dissertation. 
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S.2  F.TMiiDle 

Id  tbia  acction,  the  eoftware  d«aign  approach  ia  applied  to  an  example  o(  the 
ADS  applicatioD  software,  a robot  control  system.  This  example  was  oripnally  intro* 
duced  by  Gomaa  [24]  in  his  presentation  of  Design  Approach  for  Real-Time  Systems 
(DARTS).  The  problem  was  used  in  [40,  39,  25]  to  illustrate  the  design  methodology 
for  real-time  systems  on  uniprocessors  and  in  [39]  to  show  the  design  of  distributed 
real-time  systems  with  Ada.  The  similar  example  ia  used  in  tbia  dissertation,  and  it 
is  modified  to  illustrate  ADS  features. 

The  robot  controller  system  is  particularly  attractive  as  an  inherently  concurrent 
system  with  several  parallel  functions  [39).  Ftirtbermore,  on-line  properties  and  fault 
tolerances  are  highly  required  in  real  industry  environments. 

There  can  be  two  different  situations  in  the  design  phase,  i.e.,  designing  the  soft- 
ware with  or  without  regard  for  the  hardware  processor.  The  decomposition  results 
of  both  cases  may  be  different.  In  this  dissertation,  it  is  assumed  previously  to  decide 
the  characteristics  of  computer  network  characteristics  and  each  hardware  processor. 

Each  step  will  show  the  design  method  for  ADS  application  software.  A simplified 
version  of  the  requirement  of  the  robot  control  system  is  given  below. 

Renuitement  Specilication 

The  rolol  conW  system  consists  of  a set  o/ sensors  and  con/roiJers  and  a disploy 
device.  The  temperature  sensor  samples  current  femperature  value,  and  the  position 
sensor  samples  the  tarpel  item's  posilioa  data.  The  sampled  data  are  validated  before 
it  is  used.  The  display  devise  shows  the  neio  sampled  data.  The  positian  data  are 
saved  into  a file  whenever  a new  item's  pasitian  is  sampled.  A rofiot  control  process 
reads  and  deletes  a new  larpel  object’s  position  data.  After  reading  the  data,  the 
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Figure  8.1.  Decompceed 


10« 


Figure  8.2.  Object  communicetion  diagram  for  the  temperature  seasor  raoduJe 
robot  control  process  peneroles  control  in/ermofieu  for  each  azis's  controller.  The 
temperature  date  wiil  be  used  for  new  devices  in  the  fulure. 

The  data  flow  diagram  from  the  requirement  analyeis  phaae  ia  decomposed  into  a 
set  of  modules  Id  the  decompositioo  stage.  Figure  8.1  shows  the  decomposed  data 
flow  diagram  for  the  RCS.  Each  block  with  dashed  lioes  deootes  a module  boundary. 
There  are  seven  modules:  temperature  sensor  module  (TSM),  temperature  controller 
module  (TCM),  display  module  (DM),  hie  module  (PM)  for  the  list  of  each  item's  po- 
sition data,  positioD  sensor  module  (PSM),  and  two  robot  control  modules  (ROMs). 
The  dummy  node  in  the  diagram  ia  shown  for  the  future  extension  of  the  system. 

8.2.2  Desifti  Step 

I)The  interface  of  each  module  is  established.  The  data  process  unfidafe-daln 
in  the  TM  is  a relatively  active  component  against  the  data  process  adjusf-lemp  in 
the  TCM  and  the  data  process  odjusl-lemp  in  the  DM.  So,  the  interface  is  an  one- 
way  type  of  an  object  method.  Because  the  validated  temperature  data  are  sent  to 
the  TCM  and  the  DM  at  the  same  time,  the  virtual  object  method  name  for  the 


broadcasting  based  remote  object  method  invocation  is  used.  In  Ibe  TCM  and  the 
DM,  the  remote  object  method  ttmp!proix3s(temp‘Valna}  is  defined  as  the  export 
object  method. 

Hodole  teap-sansor-nodnla: 

inport  object  eethod:  tanp IproceeeCtenp-value) ; 

Module  teap-control -nodule: 

export  object  aetbod;  tespIprocessCtenp-value) ; 

Module  dieplaj-nodule: 

export  object  nathod;  teap!procesaCtenp-value) ; 

2)  Objects  are  identified.  The  physical  entity,  temperature  sensor,  becomes  object 
lemp-sensor  and  the  logica]  entity,  temperature  data,  becomes  the  object  Ump.  Both 
are  easily  identified  from  the  data  flow  diagram. 

3)  For  the  interface  of  tbe  class  lemp-cfoss,  the  methods  eofidefe  and  read  are  ideo* 
tilled  from  the  data  processes  oalidoti’data  and  ncd-sewor-ilato  in  the  data  flow 
diagram.  The  input  for  the  method  valijcle  is  lemp,  and  the  output  are  Ump  and 

4)  Dependency  and  communication  relationships  among  objects  ate  identified.  The 
object  communication  diagram  is  used  for  the  representation  of  these  relationships. 
In  Figure  8.2,  tbe  object  communication  diagram  for  the  TCM  is  shown.  The  links 
between  the  objects  indicate  the  method  invocations  between  the  objects.  Tbe  ar- 
rows on  the  links  iDdic:ate  the  direction  of  invocation. 

5)  The  commonality  between  diffetenl  classes  is  identified  to  establish  the  class  hierar- 
chy. The  classes,  femp-setisor-c/oss  and  posUion-seasor-class  have  the  commonality. 
Both  claases  have  tbe  method  sompfe-dola.  In  thia  case,  a superclass  sensor-cfass  is 

'Tbis  step  can  be  done  by  applying  Alabiso's  rnelbod  (3J. 


defined.  The  miperclue  sensor-c/nes  hu  the  method  jampye-dala,  that  can  be  inher- 

6)  The  composition  of  each  object  and  its  method  are  designed-  The  object  posilion- 
Jul  in  the  FM  has  a list  of  three  axis  values.  The  composition  and  methods  of  iU 
class,  posUion-list-elw  are  defined  as  follows: 

elaai  definition  poaition-llat-classfcapacitr;  integer) 

— poBition-claea  ia  defined  as  generic  clean  vith 

— a capacity  as  paranetar. 
coeposition 

positions:  list  of  (z-axis,  y-azis,  z-azis:  real), 

first, last:  pointer; 

— positions  ia  a storage  for  each  itan's  position  data  and 
--  first  and  last  indicate  the  pointers  of  the  list  positions. 

■ethod  put(z,y,z:  real) 

guard((last*l)X  capacity  !-  first); 

positions(last). z-azis  • z; 
positions(last). y-azis  ■ y; 
positions(last). z-axis  ■ z; 

Bsthod  g#t(z-y,z:  real) 

guardffirst  X capacity  !•  last); 

X ■ positions(first). z-azis; 
y • positionsCfirst). y-azis; 
z • positionsCfirst). z-axis; 
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7)  The  body  of  each  module  ii  designed.  The  body  of  the  PSM  is  defined  ss 


Body  of  Hodulof 

position:  position*clnss(0.0,  100.0,  0.0,  100.0,  0.0,  100.0); 

— object  instantintion  with  actual  parasetar  values. 

flag,  result:  boolean; 


vbile(THDE)  do 

p-senaor.raadyfflag); 
if  (flag  - me) 

than  position. read(p*aensor) ; 
posit ion. validate (result) ; 
if  (result  • TRUE) 

then  PositionlproceasCposition) ; 
p*senaor. reset 0 ; 


The  body  consists  of  object  instantiation,  such  as  the  object  poatUon  of  tbe  class 
poiilioa-clius,  and  its  own  process  description.  In  the  above  example,  whenever  p- 
sensor  is  in  tbe  ready  state,  the  position  data  ate  read  and  validated.  If  the  data  are 
correct,  then  the  remote  object  method  Poaitionlproctss  is  invoked  and  p-sensor's 
state  is  changed.  If  tbe  data  are  not  correct,  then  the  data  are  read  again. 


CHAPTERS 

DISCUSSIONS 


Id  this  diftsertation,  a software  design  approacli  for  the  ADSs  have  been  studied. 
The  approach  is  based  od  the  object-oriented  coocepts  with  incorporation  of  data 
flow  concepts.  The  computation  model  developed  in  this  dissertation  is  the  basis 
of  our  approach.  Also,  the  transformation  method  to  support  the  software  design 
from  the  requirement  analysis  phase  is  developed.  The  approach  presented  in  this 
dissertation  has  the  following  desirable  aspects  for  ADS  applicatioo  software  design: 
Ij  The  computation  model  has  desirable  features  related  to  characteristics  of  the 
ADS  software  and  iU  system  environment.  It  supports  the  data  flow  type  object 
method  for  the  inter-module  interaction.  The  modules  interfaced  with  the  data  flow 
type  object  method  are  much  more  autonomous  than  the  modules  interfaced  with  the 
client/server  type  object  method.  In  the  computation  model,  every  remote  abject 
method  is  based  on  the  logical  location  transparency,  and  data  flow  type  of  object 
method  invocation  is  supported.  Therefore,  by  using  a design  model  based  on  this 
computation  model,  the  on-line  eicpandability  of  ADS  application  software  can  be 
addressed  in  the  design  stage. 

2)  In  this  computation  model,  the  concurrent  remote  object  method  invocation  based 
on  a broadcasting  mechanism  is  possible.  It  supports  the  broadcasting  programming 
to  achieve  effective  utiliaalion  of  the  ADS  environment. 

3)  Because  our  software  design  approach  is  primarily  based  on  the  object-oriented 
concepts.  It  supports  abstraction  and  information  hiding  which  enhances  the  un- 
derslaodability  and  the  maintainability  of  software  systems.  It  also  supporU  the 
reusability  by  the  inheritance  property. 


Ill 

4)  When  the  mcxlule  inlerfscea  are  eslabiished  by  using  the  traneformatioD  metbo<l 
in  tbe  design  phase,  the  effective  utilieatioo  of  the  broadcasting  based  iater*processor 
communication  in  tbe  ADS  environments  can  be  considered.  Tbe  transformation 
rules  support  that  aspect  in  the  early  design  phase. 

5}  this  transformation  method  smoothly  linhs  the  requirement  analysis  phase,  in 
which  a data  flow  diagram  is  a primary  output  model,  Co  tbe  design  phase.  Tbe 
transformetioo  method  preserves  tbe  original  meaning  of  tbe  data  flow  diagram. 
Therefore,  the  software  designer  can  design  ADS  application  software  consistently 
and  completely. 

In  this  dissertation,  the  scope  of  the  application  area  is  the  data  flow  type  of 
software  system,  such  as  s process  control  system.  The  reason  to  choose  such  types 
of  application  areas  is  that  those  software  systems  are  frequently  evolved  during 
tbe  life  cycle  of  the  system  and  the  systems  cannot  stop  tbdr  operations  at  any 
moment.  The  data  Sow  diagram  is  the  most  suitable  model  to  represent  the  data 
Bow  types  of  software  systems.  The  transformation  method  is  similar  to  Alabiso’i[3) 
and  Toeteoel’s  [51]  approaches.  All  these  approaches  use  the  data  flow  diagram  as 
input  and  support  object-oriented  software  design.  In  table  9,  the  comparison  of  tbe 
transformation  method  to  others  is  summarized. 

In  this  dissertation,  the  object-oriented  npproach  and  computation  model  tor  the 
on-line  expandable  software  design  are  primarily  investigated.  However,  there  are 
several  future  works  in  the  software  development  approach  for  the  ADSs.  One  di- 
rection is  to  extend  this  approach  for  the  on-line  maintainable  ADS  software  dMign. 
Cunenlly,  any  software  development  methodology  has  not  addressed  that  issue,  even 
though  the  requirement  of  it  is  continuously  growing  in  many  distributed  comput- 
ing application  areas.  The  object  oriented  software  development  approach  has  been 
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Table  9.1.  CompariBon  of  our  traiufomiatiofl  method  with  others 


Approach 

Toetenel's 

AlabiBo’s 

Ours 

Input  model 

DFD 

Extended  DFD 

Extended  DFD 

Output  mode] 

VDM  notations 

Small-TalkSO 

Module/Obiect  diagram 

multicasting 

No 

No 

Ye* 

DPT  object  method  * 

No 

No 

Yet 

CST  object  method  ** 

Yes 

Ves 

Yes 

LL  transpareoev 

No 

No 

Yes 

Activation  relationihip 

Yes 

No 

Yes 

data  flow  type  object  method 
clieot/sever  type  object  method 
logically  locational  transparency 


considered  good  for  the  software  maintenance  by  many  researchers  and  software  prac- 
titioner. It  is  still  good  for  on-line  software  maintenance,  because  the  object  model 
has  major  desirable  properties  for  the  on-line  maintenance,  such  as  weah  coupling, 
high  cohesion,  information  hiding,  aod  modularity. 

The  requirement  analysis  is  another  area  for  the  future  research.  Like  any  other 
phases  of  the  software  development  for  ADSs,  the  requirement  analysis  phase  needs 
to  be  studied  much  more.  In  this  dissertation,  the  data  flow  diagrams  are  used  in 
the  requirement  analysis  phase.  The  structured  analysis  methods  are  the  most  well- 
developed 'techniques  for  the  requirement  analysis  by  using  data  Row  diagrams.  The 
major  advantage  of  the  structured  analysis  method  is  the  eiislence  of  abundant  soft- 
ware supporting  tools.  These  tools  are  still  useful  for  the  development  of  the  data  flow 
oriented  software  system,  such  as  the  process  control  system.  However,  for  different 
types  of  application  areas,  such  as  business  spplicatioa  areas,  it  cannot  be  guaran- 
teed that  it  is  still  a good  analysis  method.  An  object-oriented  analysis  approach  is 


113 


expected  to  be  more  luit&ble  because  the  software  compoaeota  for  these  applicatioD 
areas  are  mote  clieat/eerver  typed  than  data  flow  type.  Another  advantage  of  the 
object'orienled  azialyaia  approach  over  the  structured  analysis  approach  is  that  it  is 
a semanticaJly  cooslateot  way  to  interface  with  the  ob^ect-orieuted  design  method  by 
using  the  same  model  in  both  phases. 

Another  interesting  area  is  an  on-line  software  testing  approach  for  ADSs.  The 
computation  model  supports  hierarchical  encapsulation  of  software,  i.e..  module  level 
and  object  level.  Even  though  the  module  level  on-line  testing  is  available  by  the 
ADSs  system  software,  the  object  level  on-lioe  testing  is  also  valuable  for  the  bier- 
arcbial  testing  approach.  So,  how  to  dcsigo  ADS  software  easy  to  test  hierarchically 
and  development  of  some  software  tools,  such  as  integrated  Do-line  viaualization  tools 
are  very  important  areas. 

Currently,  these  areas  have  not  yet  been  fully  studied.  Continuous  research  in 
these  areas  will  be  done  io  the  future.  The  development  of  the  supporting  software 
tools  will  also  be  investigated  for  these  areas. 


SYNTAX  OF  THE  DESIGN  DESCRIPTION  LANGUAGE 


ADSpro^am  — » 

‘program’  Identifier  (module)*’ 

module  — > 

‘Module’  Identifier  {inlerface-def}-  (claae-defiaition)* 


export-obj-methode  — • 

‘export’  ‘object’  ‘method’  {r-obj-mtbd}'* 
impori'obj'methode  — » 

‘import’  ‘object’  ‘method’  {r-obj-mlhd)'*}‘ 
r*obj-mthd  — • 

obj-name  ■!'  mlhd-name '(’  parameter-list  ’)’ 

obj-name  — . 

Ideatifier 


output-parajncten 


parameter  parameter}"  *:=’  'out' 


parameter  — » 

Identifier  {‘/Identifier}’  type-name 
claas-definition  — ♦ 


‘claaa‘  'definition'  claas-name '('  clase-parametera ')’ 
'composition*  composition 
inherit  — liet“  {melhod-dfn}*  'endclass* 


Identifier 

dass-parametera  — -• 

parameter  {’/  parameter}" 


compoeition  — * 

‘I*  {Identifier  {*/  Identifier)*  type-name  }* 

inberit-liat  — • 


'from'  superclass-name  (1-obj-method}* 
stiperclass-name  — 

Identifier 


l-obj-metbod 


melhod-dfn 


‘C  parameter-list ')’  ‘;* 


'metbod'  mtbd-name  *{’  parameter-list  *)* 

guard-exp  post-cond  '{'  (statement}*  ‘)’ 


guard-exp 
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'guard’  ’('  bool-axp  *)’ 


post'cond  — ► 

‘post’  ’conditioa' 


{nrw-$tate  expresaioo 


Identifier  '* 

'Body'  ‘of’  ‘Module’ '{’  a-obj-inatanliationt}*  ')’  {statemeol}* 
s-obj-iDatantiation  — » 

obj-name  class-name  '('  initial-«lue*  ')’ 


‘while’ bool-exp  ‘do’ '{’  {aUtemenl)'’' '}’ 
rif“(’ bool-exp  ‘)"theii”{’  {statemenl}*  ’el6e“{’ {slalemeot)*  •}’ 
I ’ease’  ’’  { bool-exp  '{’  {statement)*  ’}’  }*  ’ 

I d-obj-iostantiation 
I assignment 
I mtbd-invocation 

d-obj-inslantiation  — » 

obj-name  ‘=’  ’new’  class-name  initial- values 
assignment  — t 

Identifier  expression 


I obj-n 
I obj-n 
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initial-values  — • 

IdcDtifier  {,[dea(ifier  }'^ 


expresfiioD  — > 


bool-exp  — ► 


bool-exp 

arthm-expressioe 


ortbm-expression  comp-operator  arthm-expressioa 
bool-exp  log-operator  bool-exp 


) 'TRUE' 

I -FALSE' 

IdentiHer  arthm-operalor  arthm-expressioR 
I'-'  Identifier 
I Identifier 


comp-operator  — * 


I T 


log-operator 


(=■ 

=’ 


artKm*op«rator 


I 

I 7’ 


I ‘mod' 


I complfix-lype 
complex-type  — • 

‘*rrey’ '('  dimeasiooB  *)'  ‘of'  type-Rame 
I 'eefoT  type-name 

dimeiuions  — • 


Identifier  Identifier  )* 


simple-type  — > 


'*'  Lrroo?sSSirp^%s^^  S"pis  S£‘  "“- 

'■'  ‘^riKE:  ■“  “■ 

"'  fipjESlS' ftSSuS”'"'”'”' '“® " *■''" 

'■"  SEK^as»?;ssr 


o/lk»  ACM. 
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" ‘SjSiSJ^s; 


'"'  ,';“rir,“r^''Ss" 


[28]  P.Hudai.  Par..functional  program. 


”'  ?„?,  ■■'  *-'•" «— ■ — •■ — ".. 

Sri.  Sskk^— -anss 

flri/SvHem  TecA- 

"'  Ji-varsi:  »»°v;i™»t  ,*'-'■•>  ‘■'" »-'■"'  - 


|43J  C.V,R»m»moortiy,Y.Y»w,andW.T.T»i.  Synthesis  rule,  far  ^^tir  , 


IS:S“»;=;!;  lslsi"5.r 

" %ii  ss;  Si.)'a:-SE7«¥  ““  -'-"•  "™ 
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